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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 of the LoCation Services (LCS) feature in UMTS and GSM, which provides 
the mechanisms to support mobile location services for operators, subscribers and third party service providers. 

The present document replaces the specifications TS 23. 171 (Release 1999) and the system and core network parts of 
GSM 03.71 (Release 1999). TS 43.059[16] replaces the radio access network parts of GSM 03.71 (Release 1999). 

Location Services may be considered as a network provided enabling technology consisting of standardised service 
capabilities, which enable the provision of location applications. The application(s) maybe service provider specific. 
The description of the numerous and varied possible location applications which are enabled by this technology are 
outside the scope of the present document. However, clarifying examples of how the functionality being described may 
be used to provide specific location services may be included. 

This stage 2 service description covers the LCS system functional model for the whole system, the LCS system 
architecture, state descriptions, message flows, etc. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

2.1 Normative references 

[I] 3GPP TS 25.305: "Stage 2 functional specification of UE positioning in UTRAN". 
[2] GSM 01.04 (ETR 350): "Abbreviations and acronyms". 

[3] 3GPP TS 21.905: "UMTS Abbreviations and acronyms". 

[4] 3GPP TS 22.071: "Technical Specification Group Systems Aspects; Location Services (LCS); 

Stage 1". 

[5] (void) 

[6] 3GPP TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC - BSS) 

interface; Layer 3 specification". 

[7] 3GPP TS 22.100: "UMTS phase 1 (Release 1999)". 

[8] 3GPP TS 22.101: "Service principles". 

[9] 3GPP TS 22.105: "Services and Service Capabilities". 

[10] 3GPP TS 22.1 15: "Charging and Billing". 

[II] 3GPP TS 23.032 (GSM 03.32): "Universal Geographical Area Description (GAD)". 
[12] 3GPP TS 22.121: "The Virtual Home Environment". 

[13] 3GPP TS 23.1 10: "UMTS Access Stratum Services and Functions". 
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[14] 3GPP TS 25.413: "UTRAN lu Interface RANAP signaling". 

[15] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[16] 3GPP TS 43.059: "Functional Stage 2 description of Location Services in GERAN". 

[17] 3GPP TS 23.003: "Numbering, addressing and identification". 

[18] 3GPP TS 29.002: "Mobile Application Part (MAP) Specification". 

[19] GSM 04.02: "GSM Public Land Mobile Network (PLMN) access reference configuration". 

[20] 3GPP TS 23.002: "Network architecture". 

[21] 3GPP TS 23.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL) - 

stage 2". 

[22] 3GPP TS 23.01 1: "Technical realization of Supplementary Services". 

[23] 3GPP TS 23.007: "Restoration procedures". 

[24] 3GPP TS 24.008: "Mobile Radio Interface - Layer 3 MM/CC Specification". 

[25] 3GPP TS 25.33 1 "RRC protocol specification". 

[26] 3GPP TS 23. 127 "Virtual Home Environment/Open Service Access". 

[27] 3GPP TS 29. 198-1 : 'Open Service Access (OSA); Application Programming Interface (API); Part 

1; Overview'. 

[28] 3GPP TS 29. 198-2: 'Open Service Access (OSA); Application Programming Interface (API); Part 

2; Common Data'. 

[29] 3GPP TS 29.198-3: 'Open Service Access (OSA); Application Programming Interface (API); Part 

3; Framework'. 

[30] 3GPP TS 29.198-6: "Open Service Access (OSA); AppHcation Programming Interface (API); Part 

6: Mobility". 

[31] LIF TS 101 "Mobile Location Protocol Specification" (Location Interoperability Forum) 

[Available at http://www.openmobilealliance.org/tech/LIF/] 

[32] ANSI J-STD-036A: 'Enhanced Wireless 9-1-1 Phase 2' 

2.2 Informative references 

[33] Third generation (3G) mobile communication system; Technical study report on the location 

services and technologies, ARIB ST9 December 1998. 

[34] The North American Interest Group of the GSM MoU ASSOCIATION: Location Based Services, 

Service Requirements Document of the Services Working Group. 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

CAMEL: CAMEL is a network functionality, which provides the mechanisms of Intelligent Network to a mobile user 

Call Related: any LCS related operation which is associated with an established call in CS domain and a session via an 
active PDP context in PS domain. 
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Codeword: access code, which is used by a Requestor or LCS Client in order to gain acceptance of a location request 
for a Target UE. The codeword is part of the privacy information that may be registered by a Target UE user. 

Current Location: after a location attempt has successfully delivered a location estimate and its associated time stamp, 
the location estimate and time stamp is referred to as the "current location" at that point in time 

Deferred location request: location request where the location response (responses) is (are) not required immediately 

Global Positioning System: Global Positioning System (GPS) consists of three functional elements: Space Segment 
(satellites). User Segment (receivers), and Control Segment (maintenance etc.)- The GPS receiver calculates its own 
position based on the received time differences for several satellites 

Immediate location request: location request where a single location response only is required immediately 

Initial Location: in the context of an originating emergency call the location estimate and the associated time stamp at 
the commencement of the call set-up is referred to as "initial location" 

Last Known Location: current location estimate and its associated time stamp for Target UE stored in the LCS Server 
is referred to as the "last known location" and until replaced by a later location estimate and a new time stamp is 
referred to as the "last known location" 

LCS (Location Services): LCS is a service concept in system (e.g. GSM or UMTS) standardization. LCS specifies all 
the necessary network elements and entities, their functionalities, interfaces, as well as communication messages, due to 
implement the positioning functionality in a cellular network. Note that LCS does not specify any location based (value 
added) services except locating of emergency calls 

LCS Client: software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location 
information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information. 
LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting 
data and managing the user interface (dialogue). The LCS Client may reside in the Mobile Station (UE) 

LCS Client Access barring list: optional list of MSISDNs per LCS Client where the LCS Ghent is not allowed to 
locate any MSISDN therein 

LCS Client Subscription Profile: collection of subscription attributes of LCS related parameters that have been agreed 
for a contractual period of time between the LCS client and the service provider 

LCS Feature: capability of a PLMN to support LCS Client/server interactions for locating Target UEs 

LCS Server: software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services 
requests, and sends back responses to the received requests. The LCS server consists of LCS components, which are 
distributed to one or more PLMN and/or service provider 

LDR reference number: Unique identity of a Location Deferred Request, which is assigned and maintained by the 
GMLC and circulated between the LCS Client, GMLC and MSC/SGSN. In addition, in a Periodical Immediate/deferred 
LCS Service Request, the LDR reference number is exclusive. 

Local Service: service, which can be exclusively provided in the current serving network by a Value added Service 
Provider 

Local Information: information related to a given location, or general information, which is made available in a given 
location 

Location (Based) Application: location application is an application software processing location information or 
utilizing it in some way. The location information can be input by a user or detected by network or UE. Navigation is 
one location application example 

Location Based Service (LBS): service provided either by teleoperator or a 3' party service provider that utilizes the 
available location information of the terminal. Location Application offers the User Interface for the service. LBS is 
either a pull or a push type of service (see Location Dependent Services and Location Independent Services). In 
ETSI/GSM documentation of SoLSA, LBS is called "Location Related Service". ETSI and/or 3GPP -wide terminology 
harmonization is expected here 

Location Dependent Service: service provided either by teleoperator or a 3"^ party service provider that is available 
(pull type) or is activated (push type) when the user arrives to a certain area. It doesn't require any subscription in 
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advance, but the push type activation shall be confirmed by the user. The offered service itself can be any kind of 
service (e.g. a public Xerox machine or the discount list in a store) 

Location Estimate: geographic location of an UE and/or a valid Mobile Equipment (ME), expressed in latitude and 
longitude data. The Location Estimate shall be represented in a well-defined universal format. Translation from this 
universal format to another geographic location system may be supported, although the details are considered outside 
the scope of the primitive services 

Location Independent Service: service provided either by teleoperator or a 3'*^ party service provider that is available 
and therefore can be activated anywhere in the network coverage. It is activated by the user's request or by other user's 
activated service, and therefore it requires a subscription in advance (pull type). The offered service itself can be any 
kind of service (e.g. MMS, SWDL, or LBS!) 

Mobile Assisted positioning: any mobile centric positioning method (e.g. IPDL-OTDOA, E-OTD, GPS) in which the 
UE provides position measurements to the network for computation of a location estimate by the network. The network 
may provide assistance data to the UE to enable position measurements and/or improve measurement performance 

Mobile Based positioning: any mobile centric positioning method (e.g. IPDL-OTDOA, E-OTD, GPS) in which the UE 
performs both position measurements and computation of a location estimate and where assistance data useful or 
essential to one or both of these functions is provided to the UE by the network. Position methods where an UE 
performs measurements and location computation without network assistance data are not considered within this 
category 

Mobile Station: mobile station (MS) consists of Mobile or User Equipment (ME or UE) with a valid SIM or USIM 
attached. The abbreviation "UE" in this specification refers both to MS and User Equipment, see below. 

PLMN Access barring list: optional list of MSISDN per PLMN where any LCS Client is not allowed to locate any 
MSISDN therein except for certain exceptional cases 

Positioning (/location detecting): positioning is a functionality, which detects a geographical location (of e.g. a mobile 
terminal) 

Positioning method (/locating method): method or technical solution, which is used to get an estimate of the target 
mobile's geographical location. For example positioning methods based on radio cell coverage, GPS or Assisted GPS 
methods, which are based on the Time-Of- Arrival (TO A) algorithm, and OTDOA or E-OTD methods, which are based 
on the Time-Difference-Of- Arrival (TDOA) algorithm. The positioning methods are further described in UTRAN Stage 
2, TS 25.305 [1] and GERAN Stage 2, TS 43.059 [16]. 

Predefined area: geographical area, which is not related to cell or radio coverage. The mobile may take special action 
when it recognises it has entered or left a predefined area 

Privacy Class: list of LCS Clients defined within a privacy exception class to which permission may be granted to 
locate the target UE. The permission shall be granted either on activation by the target UE or permanently for a 
contractual period of time agreed between the target UE and the service provider 

Privacy Exception List: list consisting of various types of privacy classes (i.e. operator related, personal etc.). Certain 
types of classes may require agreement between the service provider and the target UE 

Prohibited area: area where the mobile must not activate its transmitter. The Prohibited area may be a Predefined area 
described above or related to radio cell(s) 

Requestor: the originating entity which has requested the location of the target UE from the LCS client. 

Requestor Identity: This identifier is identifying the Requestor and can be e.g. MSISDN or logical name. 

Service Type: attribute of specific location based service provided by the LCS client, as defined in TS 22.071. 

Subscription Profile: profile detailing the subscription to various types of privacy classes 

Target UE: UE being positioned 

User Equipment: term 'User Equipment', or 'UE', should for GSM be interpreted as 'MS', as defined in 

GSM TS 04.02 [19]. UE in this specification may also refer to a Mobile Equipment or User Equipment used for 

emergency calls, that do not have valid SIM or USIM 

Further UMTS related definitions are given in 3GPP TS 22.101. 
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3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Gb 
Gs 

Lc 
Le 
Lg 

Lh 

Um 
Uu 



Interface between 2G-SGSN and BSS 

Interface between MSC and SGSN 

Interface between gateway MLC and gsmSCF (CAMEL interface) 

Interface between External User and MLC (external interface) 

Interface between Gateway MLC - VMSC, GMLC - MSC Server, GMLC - SGSN (gateway MLC 

interface) 

Interface between Gateway MLC and HLR (HLR interface) 

GERAN Air Interface 

UTRAN Air Interface 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

2G- Second Generation 

3G- Third Generation 

AC Admission Control 

AI Application Interface (prefix to interface class method) 

ANM Answer Message (ISUP) 

APN Access Point Name 

APN-NI APN Network Identifier 

ARIB Association of Radio Industries and Business 

ATD Absolute Time Difference 

BCCH Broadcast Control Channel 

BER Bit Error Rate 

BSS Base Station Subsystem 

BTS Base Transceiver Station 

CAMEL Customised Application For Mobile Network Enhanced Logic 

CAP CAMEL Application Part 

CM Connection Management 

CN Core Network 

CSE Camel Service Environment 

DL Downlink 

DRNC Drift RNC 

E-OTD Enhanced Observed Time Difference 

FER Frame Error Rate 

GERAN GSM EDGE Radio Access Network 

GGSN Gateway GPRS Support Node 

GMLC Gateway MLC 

GPRS General Packet Radio Service 

GPS Global Positioning System 

HE Home Environment 

HSS Home Subscriber Server 

HLR Home Location Register 

HPLMN Home Pubhc Land Mobile Network 

IMEI International Mobile Equipment Identity 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

IPDL Idle Period Downlink 

LA Location Application 

LAF Location Application Function 

LBS Location Based Services 

LCAF Location Client Authorization Function 

LCCF Location Client Control Function 

LCCTF Location Client Co-ordinate Transformation Function 

LCZTF Location Client Zone Transformation Function 

LCF Location Client Function 
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LCS Location Services 

LDR Location Deferred Request 

LIR Location Immediate Request, 

LMU Location Measurement Unit 

LSAF Location Subscriber Authorization Function 

LSBcF Location System Broadcast Function 

LSBF Location System Billing Function 

LSCF Location System Control Function 

LSOF Location System Operation Function 

LSPF Location Subscriber Privacy Function 

MAP Mobile Application Part 

ME Mobile Equipment 

MExE Mobile Execution Environment 

MLC Mobile Location Center 

MLP Mobile Location Protocol 

MM Mobility Management 

MO-LR Mobile Originated Location Request 

MS Mobile Station 

MSC Mobile Services switching Center 

MSC Mobile services Switching Centre 

MSISDN Mobile Station Integrated Services Data Network 

MT-LR Mobile Terminated Location Request 

NA-ESRD North American Emergency Service Routing Digits 

NA-ESRK North American Emergency Service Routing Key 

NI-LR Network Induced Location Request 

OSA Open Service Architecture 

OTDOA Observed Time Difference Of Arrival 

PC Power Control 

PCF Power Calculation Function 

PLMN PubUc Land Mobile Network 

POI Privacy Override Indicator 

PRCF Positioning Radio Co-ordination Function 

PRRM Positioning Radio Resource Management 

PSE Personal Service Environment 

PSMF Positioning Signal Measurement Function 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RA Routing Area 

RACH Random Access Channel 

RAN Radio Access Network 

RANAP Radio Access Network Application Part 

RIS Radio Interface Synchronization 

RNC Radio Network Controller 

RRM Radio Resource Management 

RTD Real Time Difference 

SAT SIM Application Tool-Kit 

SCCP Signalling Connection Control Part 

SCS Service Capability Server 

SGSN Serving GPRS Support Node 

SI Service Interface (prefix to interface class method) 

SIM Subscriber Identity Module 

SIR Signal Interference Ratio 

SLPP Subscriber LCS Privacy Profile 

SMLC Serving Mobile Location Center 

SMS Short Message Service 

SP Service Point 

SRNC Serving RNC 

SS7 Signaling System No 7 

TA Timing Advance 

TMSI Temporary Mobile Subscriber Identity 

TOA Time Of Arrival 

UDT SCCP Unitdata message 
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UE User Equipment 

UL Uplink 

UMTS Universal Mobile Telecommunication System 

USIM Universal Subscriber Identity Module 

UTRAN Universal Terrestrial Radio Access Network 

VASP Value Added Service Provider 

VHE Virtual Home Environment 

WCDMA Wideband Code Division Multiple Access 

Further GSM related abbreviations are given in GSM 01.04. Further UMTS related abbreviations are given in 
3GPPTS 21.905 [3]. 
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Main concepts 



A general description of location services and service requirements are given in the specification TS 22.071 [4]. The 
positioning of the UE is a service provided by the Access Network. In particular, all Access Networks (e.g. UTRAN, 
GERAN), that facilitate determination of the locations of User Equipments, shall be able to exchange location 
information with the core network as defined in the present document (when connected to a Core Network). 

By making use of the radio signals the capability to determine the (geographic) location of the user equipment (UE) or 
mobile station (UE) shall be provided. The location information may be requested by and reported to a client 
(application) associated with the UE, or by a client within or attached to the Core Network. The location information 
may also be utilised internally in the system; for example, for location assisted handover or to support other features 
such as home location billing. The position information shall be reported in standard, i.e. geographical co-ordinates, 
together with the time-of-day and the estimated errors (uncertainty) of the location of the UE according to specification 
TS 23.032 [11]. 

It shall be possible for the majority of the UE (active or idle) within a network to use the feature without compromising 
the radio transmission or signaling capabilities of the GSM/UMTS networks. 

The UE and the network may support a number of different positioning methods and the UE may support or not support 
privacy invocation request and response. The UE informs the core network and radio access network about its LCS 
capabilities in this respect as defined in TS 24.008 [24] and TS 25.331 [25]. 

The uncertainty of the location measurement shall be network design (implementation) dependent at the choice of the 
network operator, this is further described in TS 25.305 [1] and TS 43.059 [16]. 

There are many different possible uses for the location information. The positioning feature may be used internally by 
the GSM/UMTS network (or attached networks), by value-added network services, by the UE itself or through the 
network, and by "third party" services. The positioning feature may also be used by an emergency service (which may 
be mandated or "value-added"), but the position service is not exclusively for emergencies. 

4.1 Assumptions 

As a basis for the further development work on LCS in GSM and UMTS the following assumptions apply: 

positioning methods are Access Network specific, although commonalties should be encouraged between Access 
Networks; 

commercial location services are only applicable for an UE with a valid SIM or USIM; 

the provision of the location services in the Access Network is optional through support of the specified 
method(s); 

the provision of location services is optional in MSC and SGSN; 

LCS is applicable to any target UE whether or not the UE supports LCS, but with restrictions on choice of 
positioning method or notification of a location request to the UE user when LCS or individual positioning 
methods, respectively, are not supported by theUE; 

LCS shall be applicable for both circuit switched and packet switched services; 

the location information may be used for internal system operations to improve system performance; 

it shall be possible to accommodate future techniques of measurement and processing to take advantage of 
advancing technology so as to meet new service requirements; 

it may be necessary to support LCS signaling between separate access networks via the core network. The lur 
interface should be used if available. 

Provide positioning procedures through the circuit-switched domain are also applicable to GPRS UEs which are 
GPRS and IMSI attached. 
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4.2 Location Services Categories 



Generally there are four categories of usage of the location service. These are the Commercial LCS, the Internal LCS, 
the Emergency LCS and the Lawful Intercept LCS. The definition of these services and their categories is outside the 
scope of the present document. 

The Commercial LCS (or Value Added Services) will typically be associated with an application that provides a 
value-added service to the subscriber of the service, through knowledge of the UE location and if available, and 
at the operator" s discretion, the positioning method used to obtain the location estimate. This may be, for 
example, a directory of restaurants in the local area of the UE, together with directions for reaching them from 
the current UE location. 

The Internal LCS will typically be developed to make use of the location information of the UE for Access 
Network internal operations. This may include; for example, location assisted handover and traffic and coverage 
measurement. This may also include support certain O&M related tasks, supplementary services, IN related 
services and GSM bearer services and teleservices. 

The Emergency LCS will typically be part of a service provided to assist subscribers who place emergency calls. 
In this service, the location of the UE caller and, if available, the positioning method used to obtain the location 
estimate is provided to the emergency service provider to assist them in their response. This service may be 
mandatory in some jurisdictions. In the United States, for example, this service is mandated for all mobile voice 
subscribers. 

The Lawful Intercept LCS will use the location information to support various legally required or sanctioned 

services. 



4.3 Positioning methods 



The LCS feature utilises one or more positioning methods in order to determine the location of user equipment (UE). 
Determining the position of a UE involves two main steps: 

Radio signal measurements; and 

Position estimate computation based on the measurements. 

The positioning methods for UTRAN are further described in TS 25.305 [1]. 

4.3.1 Standard LCS IVIethods in UTRAN 

The specification TS 25.305 UTRAN Stage 2 specifies the locating methods to be supported: 

cell coverage based positioning method; 

OTDOA positioning method; 

GPS based positioning methods. 
For more details on these positioning methods, refer to TS 25.305 [1]. 

4.3.2 Standard LCS IVIethods in GERAN 

The specification TS 43.059 GERAN LCS Stage 2 specificies the locating methods to be supported in GERAN: 
cell coverage based positioning method; 

Enhanced Observed Time Difference (E-OTD) positioning method; 
- GPS based positioning methods. 
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4.4 Types of Location Request 
4.4.1 Immediate Location Request 



Request for location where the LCS Server replies immediately to the LCS Client with the current location estimate if 
this could be obtained. 



4.4.2 Deferred Location Request 



Request for location contingent on some current or future events where the response from the LCS Server to the LCS 
Client may occur some time after the request was sent. 



4.4.2.1 



Types of event 



a) UE available: Any event in which the MSC/SGSN has established a contact with the UE. Note, this event is 
considered to be applicable when the UE is temporarily unavailable due to inaction by the UE user, temporarily 
loss of radio connectivity or IMSI detach and so on. Note that IMSI detach is only applicable in the case UE has 
previously been registered and information is still kept in the node. 

b) Other events are FES (Release 5) 



5 General LCS architecture 

5.1 LCS access interfaces and reference points 

There is one reference point between the LCS server and LCS client called Le, see figure 5.1. The general aspects of the 
Le reference point are described in TS 22.071 [4]. Protocol specifics that may be implemented for the Le interface have 
been specified by LIE (Location Inter-operability Eorum) [31]. There may be more than a single LCS network interface 
to several different LCS clients or other networks. These networks may both differ in ownership as well as in 
communications protocol. The network operator should define and negotiate interconnect with each external LCS client 
or other network. 

An interface differs from a reference point in that an interface is defined where specific LCS information is exchanges 
and needs to be fully recognized. 

There is an interface called Lg that connects two independent LCS networks (different PLMNs) for message exchange. 




Figure 5.1 : LCS Access Interfaces and Reference Points 
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5.2 LCS Functional diagram, high level functions 

TS 22.071 [4] describes LCS services from the LCS client point of view. In the present document, a more detailed 
description of LCS is given. The LCS functional diagram shown in figure 5.2 depicts the interaction of the LCS client 
and the LCS server within the PLMN. The PLMN uses the various LCS components within the LCS server to provide 
the target UE Location Information to the LCS client. 
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Figure 5.2: LCS capability server Functional Diagram 

The following list gives the logical functional entities for the LCS. Two main functional groupings are defined which 
encompass a number of smaller functions. 

The LCS Functional entities are grouped as follows: 
the LCS Client functional group; 

the LCS Server functional group consists of functions in the UMTS PLMN supporting LCS: 

client handling component; 

system handling component; 

subscriber handling component; 

- positioning component. 

The functions of the LCS Client and the LCS Server in the PLMN are described in more detail in this clause. 

The allocation of LCS functions to network elements is specified in clause 6. 
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5.3 LCS Client functional group 



An LCS client contains an LCS component with one or more client(s), which by using location information can provide 
location, based services. 

An LCS client is a logical functional entity that requests from the LCS server in the PLMN location information for one 
or more than one target UE within a specified set of parameters such as Quality of Service (QoS). The LCS Client may 
reside in an entity (including the UE) within the PLMN or in an entity external to the PLMN. 

The specification of the LCS Client's internal logic and its relation to the external use is outside the scope of the present 
document. 

5.3.1 External Location Client Function (LCF) 

The Location Client Function (LCF) provides a logical interface between the LCS client and the LCS server. 

This function is responsible for requesting location information for one or more UEs, with a specified "QoS" and 
receiving a response, which contains either location information or a failure indicator. 

[Editor's note: this is only possible if the location request originates in the core network]. 



5.4 LCS Server functional group 



The LCS server functional group consists of the functions that are needed for GSM and UMTS to support Location 
Services. 

5.4.1 Client handling component 

5.4.1 .1 Location Client Control Function (LCCF) 

The Location Client Control Function (LCCF) manages the external interface towards LCF. The LCCF identifies the 
LCS client by requesting client verification and authorization (i.e. verifies that the LCS client is allowed to position the 
subscriber) through interaction with the Location Client Authorization Function (LCAF). The LCCF handles mobility 
management for location services (LCS) e.g., forwarding of positioning requests to VMSC or SGSN. The LCCF 
determines if the final positioning estimate satisfies the QoS for the purpose of retry/reject. The LCCF provides flow 
control of positioning requests between simultaneous positioning requests. It may order the Location Client Co-ordinate 
Transformation Function (LCCTF) to perform a transformation to local co-ordinates. It also generates charging and 
billing related data for LCS via the Location System Billing Function (LSBF). 

5.4.1 .2 Location Client Authorization Function (LCAF) 

The Location Client Authorization Function (LCAF) is responsible for providing access and subscription authorization 
to a client. Specifically, it provides authorization to a LCS client requesting access to the network and authorizes the 
subscription of a client. LCAF provides authorization to a LCS client requesting Location Information of a specific UE. 

5.4.1.2.1 Access Subfunctlon 

An Access Subfunction enables LCS clients to access LCS services. This subfunction provides verification and 
authorization of the requesting client. 

When a LCS is requested, the Access Subfunction uses the information stored in the LCS client subscription profile to 
verify that: 

the LCS client is registered; and 

the LCS client is authorized to use the specified LCS request type; 

the LCS client is allowed to request location information for the subscriber(s) specified in the LCS request. 
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5.4.1.2.2 Subscription Subfunction 

The LCS client Subscription profile shall contain a minimum set of parameters assigned on per LCS client basis for an 
agreed contractual period. The LCS client profile shall contain the following set of access parameters: 

LCS client identity; 

allowed LCS request types (i.e. LIR, LDR or both) (see note); 

maximum number of subscribers allowed in a single LCS request; 

- priority; 

- position override indicator; 
state(s); 

event(s) (applicable to LDR requests only); 

local coordinate system; 

LCS client access barring list (optional); 

PLMN access barring list applicability. 

NOTE: LIR = Location Immediate Request; and 
LDR = Location Deferred Request. 

For certain authorized LCS client internal to the PLMN, a subscription profile is unnecessary. These clients are 
empowered to access any defined service that is not barred for an UE subscriber. This permits positioning of emergency 
calls without the need for pre-subscription. 

5.4.1 .3 Location Client Co-ordinate Transformation Function (LCCTF) 

The Location Client Co-ordinate Transformation Function (LCCTF) provides conversion of a location estimate 
expressed according to a universal latitude and longitude system into an estimate expressed according to a local 
geographic system understood by the LCF and known as location information. The local system required for a 
particular LCF will be either known from subscription information or explicitly indicated by the LCF. 

5.4.1 .4 Location Client Zone Transformation Function (LCZTF) 

The Location Client Zone Transformation Function (LCZTF) performs transformations of a location (latitude and 
longitude) into a zone identity, which in North America identifies a particular emergency services zone. 

5.4.2 System handling component 

5.4.2.1 Location System Control Function(LSCF) 

The Location System Control Function (LSCF) is responsible for co-ordinating location requests. This function 
manages call-related and non-call-related positioning requests of LCS and allocates network resources for handling 
them. The LSCF retrieves UE classmark information for the purpose of determining the LCS capabilities of UE. 

The LSCF performs call setup if required as part of a LCS e.g., putting the UE on dedicated radio resources. It also 
caters for co-ordinating resources and activities with regard to requests related to providing assistance data needed for 
positioning. This function interfaces with the LCCF, LSPF, LSBF and PRCF. Using these interfaces, it conveys 
positioning requests to the PRCF, relays positioning data to the LCCF and passes charging related data to the LSBF. 

The U-LSCF for UTRAN is further described in TS 25.305 [1], LSCF for GERAN is described in TS 43.059 [16]. 



£75/ 



3GPP TS 23.271 version 5.1 2.0 Release 5 21 ETSI TS 1 23 271 V5.1 2.0 (2004-09) 

5.4.2.2 Location System Billing Function (LSBF) 

The Location System Billing Function (LSBF) is responsible for charging and billing activity within the network related 
to location services (LCS). This includes charging and billing of both clients and subscribers. Specifically, it collects 
charging related data and data for accounting between PLMNs. 

5.4.2.3 Location System Operations Function (LSOF) 

The Location System Operations Function (LSOF) is responsible for provisioning of data, positioning capabilities, data 
related to clients and subscription (LCS client data and UE data), validation, fault management and performance 
management of LCS. 

An LSOF may be associated with each entity. 

5.4.2.4 Location System Broadcast Function (LSBcF) 

The Location System Broadcast Function (LSBcF) provides broadcast capability. The LSBcF capability is only used 
when broadcast data is required for E-OTD, OTDOA or assisted GPS positioning methods. 

5.4.3 Subscriber handling Component 

5.4.3.1 Location Subscriber Authorization Function (LSAF) 

The Location Subscriber Authorization Function (LSAF) is responsible for authorizing the provision of a location 
service (LCS) for a particular mobile station (UE with SIM/USIM). Specifically, this function validates that a LCS can 
be applied to a given subscriber. In case LCF is in the UE then LSAF verifies that the UE subscriber has subscribed to 
the requested LCS service. 

5.4.3.2 Location Subscriber Privacy Function (LSPF) 

The Location Subscriber Privacy function is responsible performs all privacy related authorizations. For a target UE it 
shall authorize the positioning request versus the privacy options of the target UE, if any. 

5.4.4 Positioning components 

The positioning components Positioning Radio Co-ordination Function (PRCF), Positioning Calculation Function 
(PCF), Positioning Signal Measurement Function (PSMF) and Positioning Radio Resource Management (PRRM) are 
described in documents specific to each Access Network type. 

For location services the Access Network shall send the result of the positioning to the core network in geographical co- 
ordinates as defined in TS 23.032. The Access Network shall map the cell(s) the Target UE is associated with into 
geographical co-ordinates, but this mapping is not standardized. 

These entities are defined in TS 25.305 [1] for UTRAN and in TS 43.059 [16] for GERAN. 

5.5 Information Flows between Client and Server 

Other types of national specific information flows may be supported in addition to the information flow specified here. 

Any of the information flows here indicated may not be externally realized if the information does not flow over an 
open interface. On the other hand, if a flow goes over an open interface, it shall abide to a well-defined protocol, e.g. 
LIFTS 101 [31], Location Inter-Operability Forum 2001. 

5.5.1 Location Service Request 

Via the Location Service Request, the LCS client communicates with the LCS server to request for the location 
information of one or more than one UE within a specified quality of service. There exist two types of location service 
requests: 
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Location Immediate Request (LIR); and 

Location Deferred Request (LDR). 

The attributes for the information exchange between the LCS Client and the LCS Server have been standardized by LIF 
based on requirements set by TS 22.071 and TS 23.271. 

The following attributes are identified for Location Service Request information flow: 

Target UE identity; 

- LCS Client identity; 
Service identity, if needed; 
Codeword, if needed; 
Requestor identity, if needed; 

- Number dialled by the target mobile user or APN-NI, if the request is call or session related ; 
Event, applicable to deferred location requests only; 

Start time, stop time and interval, applicable to periodical and deferred requests only; 
Requested Quality of Service information, if needed; 

- Type of location, i.e. current location or last known location; 
Priority, if needed; 

Local coordinate reference system, if needed; 

Geographical area, if needed. 

Some of the information may be stored in GMLC and the LCS client does not need to include such information in 
the location service request. 

5.5.2 Location Service Response 

The LCS server (GMLC) sends the Location Service Response to the LCS client either as an: 

Immediate Response; or a 

Deferred Response, these deferred responses can be either single or periodic. 

The following attributes are identified for the Location Service Response information flow: 

Location indication of UE in geographical coordinates expressed as a shape as defined in TS 23.032 or local 
coordinate system; 

The information about the positioning method used to obtain the location estimate of the UE, if it is available at 
the LCS server and if needed; 

Indication when UE enters or leaves the Geographical area, if needed; 

Acknowledgement for a deferred location request, if needed. 

LDR reference number, if needed. 

In addition the information attributes of the location service request may be used also in the location service response. 
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LCS Architecture 



Figure 6.1 shows the general arrangement of the Location Service feature in GSM and UMTS. This illustrates, 
generally, the relation of LCS Clients and servers in the core network with the GERAN and UTRAN Access Networks. 
The LCS entities within the Access Network communicate with the Core Network (CN) across the A, Gb and lu 
interfaces. Communication among the Access Network LCS entities makes use of the messaging and signaling 
capabilities of the Access Network. 

As part of their service or operation, the LCS Clients may request the location information of UE. There may be more 
than one LCS client. These may be associated with the GSM/UMTS networks or the Access Networks operated as part 
of a UE application or accessed by the UE through its access to an application (e.g. through the Internet). 

The clients make their requests to a LCS Server. There may be more than one LCS Server. The client must be 
authenticated and the resources of the network must be co-ordinated including the UE and the calculation functions, to 
estimate the location of the UE and result returned to the client. As part of this process, information from other systems 
(other Access Networks) can be used. As part of the location information returned to the client, an estimate of the 
accuracy of the estimate and the time-of-day the measurement was made may be provided. 
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NOTE 1 : HSS includes both 2G-HLR and 3G-HLR functionality. LCS is included in the overall networl< architecture 

in TS 23.002 [20]. 
NOTE 2: LIF-MLP may be used on the Le interface 
NOTE 3: As one alternative the LCS client may get location information directly from GIVILC, which may contain 

OSA l\/lobility SCS with support for the OSA user location interfaces. See TS 23.127 [26] and TS 29.198 

[27, 28, 29 and 30]. 

Figure 6.1 : General arrangement of LCS 

6.1 Schematic functional description of LCS operations 

The allocation of LCS functional blocks to the Client, LCS server. Core Network, Access Network and UE is based on 
the schematic functional description below. The detailed functions and interactions are specified later in the present 
document and in TS 25.305 [1] for UTRAN, in TS 43.059 [16] for GERAN and in corresponding Stage 3 
specifications. 
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The operation begins with a LCS Client requesting location information for a UE from the LCS server. The LCS server 
will pass the request to the LCS functional entities in the core network. The LCS functional entities in the core network 
shall then: 

verify that the LCS Client is authorized to request the location of the UE or subscriber; 

verify that LCS is supported by the UE; 

establish whether it is allowed to locate the UE or subscriber, for privacy or other reasons; 

establish which network element in the Access Network should receive the Location request; 

request the Access Network (via the A, Gb or lu interface) to provide location information for an identified UE, 
with indicated QoS; 

receive information about the location of the UE from the Access Network and forward it to the Client; 

send appropriate accounting information to an accounting function. 

The Access Network LCS functional entities shall determine the position of the target UE according to TS 25.305 [1] 
for UTRAN and TS 43.059 [16] for GERAN. 



6.2 



Allocation of LCS functions to network elements 



Table 6.1 shows a summary of the Functional Groups and Functional Blocks for Location services. Table 6.2 and 
figure 6.2 show the generic configuration for LCS and the distribution of LCS functional blocks to network elements. 
Different positioning methods, including network-based, mobile-based, mobile-assisted and network-assisted 
positioning methods may be used. With this configuration both the network and the mobiles are able to measure the 
timing of signals and compute the mobile's location estimate. Depending on the applied positioning method it is 
possible to utilise the corresponding configuration containing all needed entities. For instance, if network-based 
positioning is applied, the entities that are involved in measuring the mobile's signal and calculating its location estimate 
are allocated to the network elements of the access stratum. On the other hand, in case mobile-based or network-assisted 
methods are used these entities should be allocated to the UE. 

LCS is logically implemented on the network structure through the addition of one network node, the Mobile Location 
Center (MLC). It is necessary to name a number of new interfaces. The LCS generic architecture can be combined to 
produce LCS architecture variants. 

Table 6.1 : Summary of Functional Groups and Functional Blocks for Location services 



Funct. 
Group 


Functional 
component 


Full name of Functional Block 


Abbrev. 


Loc. 
Client 


Location Client 
Component 


(External) Location Client Function 


LCF 


Internal Location Client Function 


LCF 
-internal 






LCS 

Server 

in PLMN 


Client handling 
component 


Location Client Control Function 


LCCF 


Location Client Authorization Function 


LCAF 


Location Client Zone Transformation Function 


LCZTF 


System handling 
component 


Location System Control Function 


LSCF 


Location System Billing Function 


LSBF 


Location System Operations Function 


LSOF 


Subscr. handling 
component 


Location Subscriber Authorization Function 


LSAF 


Location Subscriber Privacy function 


LSPF 


Positioning 
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Positioning Signal Measurement Function 
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Table 6.2 and figure 6.2 illustrate the allocation of functional entities in the reference configuration of LCS. It is 
assumed that the CS and PS have either their own independent mobility management or use the joint mobility 
management through the optional Gs interface. 
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It is also seen that LCS may take benefit of the lur interface between RNCs, when uplink radio information and 
measurement results are collected. 

The functional model presented in the figure includes functional entities for both CS and PS related LCS. In addition, it 
consists of all the entities needed for different positioning methods, i.e. network based, mobile based, mobile assisted, 
and network assisted positioning, exploiting either uplink or downlink measurements. It is noted that the UE may use 
e.g. the GPS positioning mechanism, but still demand e.g. auxiliary measurements from the serving network. RAN 
specific functional entities are specified in TS 25.305 [1] for UTRAN and in TS 43.059 [16] for GERAN. 

Table 6.2: Allocation of LCS functional entities to network elements 
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Figure 6.2: Generic LCS Logical Architecture 

6.3 Functional description of LCS per network element 

6.3.1 Access Network 

The Access Network is involved in the handling of various positioning procedures. 

The LCS specific functionalities of the radio access network elements are specified in TS 25.305 [1] for UTRAN and 
TS 43.059 [16] for GERAN. 

6.3.2 LCS Clients, LCS applications and Requestors 

There are two classes of LCS Application - Internal applications and External applications. Internal applications 
represent entities internal to the GSM/UMTS that make use of location information for the (improved) operation of the 
network. Internal LCS client can be identified by LCS client internal ID. LCS client Internal ID distinguishes the 
following classes: (LCS client broadcasting location related information, O&M LCS client in the HPLMN, O&M LCS 
client in the VPLMN, LCS client recording anonymous location information, LCS Client supporting a bearer service, 
teleservice or supplementary service to the target UE). External applications represent entities (such as Commercial or 
Emergency services) that make use of location information for operations external to the mobile communications 
network. External LCS client can be identified by LCS client external ID. The LCS Applications interface to the LCS 
entities through their Location Client functions (LCF). Location requests from the external LCS clients may be 
originated by external entities (i.e. Requestor). LCS client should authenticate the Requestor Identity but this is outside 
the scope of this specification. 

The LCS Client, LCS applications and Requestors are outside the scope of the present document. However, an external 
LCS Client may communicate with the LCS Server as specified in [31]. 
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6.3.3 Gateway Mobile Location Center, GMLC 

The Gateway Mobile Location Center (GMLC) contains functionality required to support LCS. In one PLMN, there 
may be more than one GMLC. 

The GMLC is the first node an external LCS client accesses in a GSM PLMN (i.e. the Le reference point is supported 
by the GMLC). The GMLC may request routing information from the HLR or HSS via the Lh interface. After 
performing registration authorization, it sends positioning requests to either VMSC, SGSN or MSC Server and receives 
final location estimates from the corresponding entity via Lg interface. 

6.3.4 LCS support in tine UE 

The UE may be involved in the various positioning procedures. Specific UE involvement is specified in each of the 
positioning procedures specified in TS 25.305 [1] for UTRAN and TS 43.059 [16] for GERAN. 

The UE interacts with the measurement co-ordination functions to transmit the needed signals for uplink based LCS 
measurements and to make measurements of downlink signals. The measurements to be made will be determined by the 
chosen location method. 

The UE may also contain LCS applications, or access a LCS application through communication with a network 
accessed by the UE or an application residing in the UE. This application may include the needed measurement and 
calculation functions to determine the UE's location with or without assistance of the GSM/UMTS LCS entities. 

In GSM the positioning methods supported by the UE are signalled by the UE to the core network and radio access 
network using Classmark3 in CS mode, as specified in TS 24.008 [24]. 

In UMTS the UE capability to support different positioning methods is only communicated within UTRAN, as 
specified in TS 25.331 [25]. 

The UE informs the core network about its capability to support privacy invocation request and response using 
Classmark2 in CS mode and MS Network Capability in PS mode, as specified in TS 24.008 [24]. 

The UE may also, for example, contain an independent location function (e.g. Global Satellite Positioning Service GPS) 
and thus be able to report its location, independent of the RAN transmissions. The UE with an independent location 
function may also make use of information broadcast by the RAN that assists the function. 

6.3.5 MSC/VLR 

The MSC/VLR contains functionality responsible for UE subscription authorization and managing call-related and 
non-call related positioning requests of LCS. The MSC is accessible to the GMLC via the Lg interface. The LCS 
functions of MSC are related to charging and billing, LCS co-ordination, location request, authorization and operation 
of the LCS services. If connected to SGSN through the Gs interface, it checks whether the UE is GPRS attached to 
decide whether to page the UE on the A/Iu or Gs interface. 

The MSC/VLR may inform HLR/HSS about the UE"s LCS Capabilities in the MAP UPDATE LOCATION message, 
during Registration and Inter MSC Update Location procedures. 

6.3.6 MSC Server 

The MSC Server handles the same functionality as the MSC/VLR including charging and billing, LCS co-ordination, 
location request, authorization and operation of the LCS services. The MSC Server is accessible to the GMLC via the 
Lg interface. 

6.3.7 SGSN 

The SGSN contains functionality responsible for UE subscription authorization and managing positioning requests of 
LCS. The SGSN is accessible to the GMLC via the Lg interface. The LCS functions of SGSN are related to charging 
and billing, LCS co-ordination, location request, authorization and operation of the LCS services. 

The SGSN may inform HLR/HSS about the UE"s LCS Capabilities for GPRS in the MAP UPDATE GPRS 
LOCATION message, during Attach and Inter SGSN Routing Area Update procedures. 
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The SGSN forwards the circuit-swiched paging request received from the Gs interface to the BSS/RNC. 

6.3.8 Home Location Register, HLR 

The HLR contains LCS subscription data and routing information. The HLR is accessible from the GMLC via the Lh 
interface. For a roaming UE, HLR may be in a different PLMN. 

6.3.9 HSS 

The HSS contains LCS subscription data and routing information. The HSS is accessible from the GMLC via the Lh 
interface. For roaming UEs, HSS may be in a different PLMN. 

6.3.10 gsmSCF 

The Lc interface supports CAMEL access to LCS and is applicable only in CAMEL [phase 3?]. The procedures and 
signaling associated with it are defined in TS 23.078 [21] and TS 29.002 [18], respectively. 

6.4 Addressing the target UE for LCS purposes 

6.4.1 Verinyms for tine target UE 

It shall be possible to address and indicate the target UE using MSISDN. It may be possible in certain cases to address 
the target UE using IP address when a static or dynamic IP address (IPv4 or IPv6) has been allocated for the UE. 

In the mobile terminated location request procedures in the PS domain (as well as in the CS domain), the target UE is 
always identified using MSISDN. 

NOTE: It is recognized that IP-addressing of the target UE is only possible when there is an active PDP context 
established between the target UE and the external LCS client. Using the established PDP context, the 
LCS client can request the target UE, as identified with the IP address it currently uses, to initiate a 
Mobile originated location request. The actual signaling exchange between the LCS Client/server and the 
target UE or the user of the target UE is outside the scope of this specification. The resulting MO-LR is 
performed as specified in this document. 

6.4.2 VOID 

6.4.3 Non-dialable callback numbers 

In case of a SIM -less emergency call, a non-dialable callback number may be used to identify the target UE. The format 
and structure of the non-dialable callback number is according to national or regional regulations. The non-dialable 
callback number in North America shall be, according to J-STD-036 [32], the digits 911 H- the last 7 digits of IMEI 
expressed in decimal numbers. 



7 Signaling and Interfaces 

7.1 LCS signaling between Access and Core Networks 

The core network sends location requests to the access network, which then sends the corresponding responses back to 
the core network. 

Communication between access and core networks is accomplished through lu interface in UMTS whereas the A, Gb 
and lu interfaces are used for the purpose in GSM (see TS 25.305 [1] and TS 43.059 [16]). 
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7.1 .1 Core network Location Request 



The core network request for a location estimate of a target UE shall contain sufficient information to enable location of 
the Target UE according to the required QoS using any positioning method supported by the PLMN and, where 
necessary, UE. For location services the core network may request the geographical co-ordinates of the Target UE. 

In UMTS the core network may also request in which Service Area the Target UE is located. The Service Area 
information may be used for routing of corresponding Emergency calls, or for CAMEL services. (The MSC Server or 
SGSN shall not send the Service Area Identity to GMLC). 

In GSM this corresponds to the usage of Cell ID in the core network. 

It should be noted that the Service Area concept is different from the Localized Service Area concept used for SoLSA 
services. 

When the location of a Target UE in Idle Mode is requested, the core network shall determine which RAN entity is 
associated with the Target UE. 



7.1.2 Location Report 



The access network reports the location of the Target UE to the core network entities. The location report may contain 
the following information as defined in the corresponding location request: 

the geographical co-ordinates of the Target UE; 

the positioning method used to obtain the location estimate, if the access network is either GERAN in the A/Gb 
mode, GERAN in the lu mode or UTRAN in the lu mode; 

the service area in which the Target UE is located; 

achieved quality level of the location estimate. 

7.2 Um and Uu Interfaces 

NOTE: This chapter may change depending on whether air interface LMU will exists in the logical architecture 
or not. 

The Um and Uu interfaces are used to communicate among the LCS entities associated with the BSC and RNC, the UE 
and the stand-alone Location Measurement Units (LMU). The Um and Uuinterfaces are also used to communicate 
between the LCS entities in the core network and the UE. 

The Um/Uu interfaces may pass measurement requests and results to and from UE or the stand-alone LMU. 

The Um/Uu interfaces may also pass location requests from internal or external LCS Clients (Applications) at the UE. 
Note that these requests may require the services of the LCS entities associated with the core network to authenticate 
clients and subscriber subscriptions to aspects of the LCS. 

The Um/Uu interfaces may also be used for broadcast of information that may be used by the UE or stand-alone LMU 
for their LCS operations. This may, for example, include timing information about nearby Node-B/BTS transmissions 
that may assist the UE or LMU in making their measurements. In UTRAN code information may be included. 

The Um and Uu interfaces may also pass messages relating to changes or reporting of the data associated with the 
Location System Operations Function (LSOF) in the UE or the remote LMU. 

UTRAN Stage 2 specification TS 25.305 [1] specifies LCS signaling over the Uu interface and GERAN Stage 2 
specification TS 43.059 [16] over the Um interface correspondingly. 

Message segmentation is specified in GERAN LCS Stage 2, TS 43.059 [16]. 

7.3 MAP Interfaces 

The following interfaces are based on MAP in LCS . 
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Lh interface: interface between GMLC and HLR. This interface is used by the GMLC to request the address of 
the visited MSC or SGSN for a particular target UE whose location has been requested. 

- Lg interface interface between GMLC MSC and GMLC - SGSN. This interface is used by the GMLC to convey 
a location request to the MSC or SGSN currently serving a particular target UE whose location was requested. 
The interface is used by the MSC or SGSN to return location results to the GMLC. 

Lc: interface between GMLC and gsmSCF, CAMEL. This interface is used to get location information for 
CAMEL based services. 

The following MAP services are defined for LCS. 

- MAP-SEND-ROUTING-INFO-FOR-LCS Service. 

This service is used between the GMLC and the HLR/HSS to retrieve the routing information needed for routing a 
location service request to the serving VMSC , SGSN. The service may be used in GMLC - HSS interface to retrieve 
routing information in order to route the location service request to the correct VMSC, SGSN and MSC Server. 

- MAP-PROVIDE-SUBSCRIBER-LOCATION Service. 

This service is used by a GMLC to request the location of a target UE from the visited MSC, SGSN or MSC Server at 
any time. 

- MAP-SUBSCRIBER-LOCATION-REPORT Service. 

This service is used by a VMSC, SGSN or MSC Server to provide the location of a target UE to a GMLC when a 
request for location is either implicitly administered or made at some earlier time. 

The MAP Subscriber Location Report could also be used to send information about location of the Target UE (for 
MO-LR) to an external client. 



8 General network location procedures 

8.1 State description for GMLC 

8.1.1 GMLC states 

8.1.1.1 NULL state 

In the NULL state, a particular location request from some LCS client either has not been received yet or has already 
been completed. After a location request is received from a LCS client, the GMLC remains in the NULL state while the 
identity of the client and nature of its location request are verified. While the NULL state exists conceptually, it need 
not be represented explicitly in the GMLC. 

8.1 .1 .2 INTERROGATION State 

In this state, the GMLC has sent an interrogation to the home HLR/HSS of the UE to be located and is awaiting a 
response giving one or several of the following addresses:the VMSC, MSC Server, SGSN address and IMSI for this 
UE. 

8.1.1.3 LOCATION State 

In this state, the GMLC has sent a location request to the VMSC, MSC Server, SGSN or serving the UE to be located 
and is awaiting a response containing a location estimate. 
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8.1.2 State functionality 
8.1.2.1 State Transitions 



ocation Request - 
terrogate HLR/HSS 

for 
MSC/SGSN/MSC 
Server address 



Location Request - 

GMLC knows VMSC 

/SGSN/MSC Server 

address 





Receive 

VMSC/SGSN/MSC 

Server address from 

HLR/HSS 

Figure 8.1 : State Transitions in thie GIVILC 

Moving from NULL to INTERROGATION state: 

If the GMLC does not know any of the following addresses: VMSC, MSC Server, SGSN address or IMSI when it 
receives a location service request from some LCS client, it moves from the NULL state to the INTERROGATION 
state and sends a request to the UE's home HLR/HSS for the VMSC/ MSC Server/ SGSN address and IMSI. 

Moving from NULL to LOCATION state: 

If the GMLC already knows one of the following addresses: VMSC, MSC Server, SGSN or UE IMSI, when it receives 
a location service request from some LCS client (e.g. from information retained for an earlier location request for the 
same UE), it moves from the NULL state to the LOCATION state and sends a location request to either the VMSC, 
MSC Server or SGSN. 

NOTE: It is for further study how GMLC selects if it shall send the location request to VMSC, MSC server 
and/or SGSN in different cases. This should be specified in the signaling procedures. 

Moving from INTERROGATION to LOCATION state: 

After the GMLC, in the INTERROGATION state, receives one or several of the addresses VMSC, MSC Server, SGSN, 
and IMSI from the home HLR/HSS, it enters the LOCATION state and sends a location request to either the VMSC, 
MSC Server or SGSN of the UE being located. 

Moving from LOCATION to NULL state: 

After the GMLC receives a location estimate response from the VMSC, MSC Server or SGSN, it forwards the location 
estimate to the requesting LCS client and re-enters the NULL state. 



8.1.2.2 



INTERROGATION Timer Function 



The GMLC runs a timer while in the INTERROGATION state to limit the amount of time waiting for an interrogation 
response from the HLR/HSS. If the timer expires before an interrogation response is received, the GMLC indicates a 
location failure to the LCS client and re-enters the NULL state. 



£75/ 



3GPP TS 23.271 version 5.12.0 Release 5 



32 



ETSI TS 123 271 V5.12.0 (2004-09) 



8.1.2.3 



LOCATION Timer Function 



The GMLC runs a timer while in the LOCATION state to Hmit the amount of time waiting for a location estimate 
response from the VMSC/ MSC Server /SGSN. If the timer expires before a response is received, the GMLC indicates a 
location failure to the LCS client and re-enters the NULL state. 

8.2 State description for VIVISC and IVISC Server 
8.2.1 VIVISC and MSC Server States 

NOTE: Periodic location service may need to be covered in the state descriptions. 



8.2.1.1 



LCS IDLE State 



In this state, the VMSC/MSC Server location service is inactive for a particular UE. The UE may be known in the 
VMSC/MSC Server (except for a USIM less or SIM less Emergency call or where the UE information has been 
cancelled or lost in the VMSC/MSC Server), but there may not be an active Mobility Management to the UE. 

8.2.1.2 LOCATION State 

In this state, the VMSC/MSC Server is awaiting a response from RAN after requesting the location for a particular UE. 

8.2.2 State Functionality 
8.2.2.1 State Transitions 



Request 
Location fro 
the RAN 




Receive 
Location 
results from the 
RAN or 
Timeout 



Transfer 
Positioning 

Messages 

Figure 8.2: State Transitions in the VIVISC/IVISC Server 

Moving from LCS IDLE to LOCATION state: 

After a request has been received to locate a particular UE and the UE subscription options have been verified, a 
location request is sent to the RAN of the UE to be located: the VMSC/MSC Server then enters the LOCATION state. 
Before entering this state, the VMSC/MSC Server must have setup a Mobility Management connection to the UE if 
none was previously active. The mobile is paged and authenticated before positioning. 

Moving from LOCATION to LCS IDLE state: 

After the return of a location estimate result from RAN, the VMSC/MSC Server shall re-enter IDLE state. 
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8.2.2.2 



LOCATION Timer Function 



TheVMSC/MSC Server runs a timer while in the LOCATION state to limit the amount of time waiting for a location 
response from the RAN. If the timer expires before such information is received, the VMSC/MSC Server indicates a 
location failure to the original requesting entity and re-enters IDLE state. 

8.3 LCS State description for SGSN 
8.3.1 SGSN States 



8.3.1.1 



LCS IDLE State 



In this state, the SGSN location service is inactive for a particular UE. The UE is known in the SGSN except in case 
where the UE data has been cancelled or lost in the SGSN. There is not an active Mobility Management to the UE. 



8.3.1.2 



LOCATION State 



In this state, the SGSN is awaiting a response from the RAN after requesting the location for a particular UE. In this 
state, a Mobility Management connection to the target UE will be active. 

8.3.2 State Functionality 
8.3.2.1 State Transitions 
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Figure 8.3: State Transitions in thie SGSN 

Moving from LCS-IDLE to LOCATION state: 

After a request has been received to locate a particular UE and the UE subscription options have been verified to allow 
this, the SGSN sends a location request to the RAN. The SGSN then enters the LOCATION state. Before entering this 
state, the SGSN must have setup a Mobility Management connection to the UE if none was previously active. The 
mobile is paged and authenticated before positioning. 

Moving from LOCATION to LCS IDLE state: 

After the return of a location estimate result from RAN, or if the Location Timer described below expires, the SGSN 
shall re-enter IDLE state. 
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8.3.2.2 LOCATION Timer Function 

The SGSN runs a timer while in the LOCATION state to limit the amount of time waiting for a location response from 
the RAN. If the timer expires before such information is received, the SGSN indicates a location failure to the original 
requesting entity and re-enters IDLE state. 

8.4 Signaling connection for the lu interface 

When using the lu interface, before SGSN/MSC server can request location information of a target UE from RAN, an 
lu signaling connection must have been established between SGSN/MSC server and RAN. The SGSN/MSC server 
sends a location request message to RAN, which determines the location of the target UE related to this lu signaling 
connection and sends a location report to SGSN/MSC server over the same lu signaling connection. 

8.5 Signaling connection for the A-interface 

When using the A interface, before MSC can request location information of a target UE from RAN, an A interface 
signaling connection must have been established between MSC and RAN. The MSC sends a location request message 
to RAN, which determines the location of the target UE related to this A interface signaling connection and sends a 
location report to MSC over the same A interface signaling connection. 

8.6 Gb interface mapping of target UE 

The pre-requisite for LCS procedures on the Gb interface is that UE is in "ready state". 



9 General Network Positioning Procedures 

The generic network positioning procedure of providing the location information of an UE subscriber can be partitioned 
into the following procedures. 

Location Preparation Procedure 

This generic procedure is concerned with verifying the privacy restrictions of the UE subscriber, reserving network 
resources, communicating with the UE to be located and determining the positioning method to be used for locating the 
UE subscriber based on the requested QoS and the UE and network capabilities. 

Positioning Measurement Establishment Procedure 

This procedure is concerned with performing measurements by involving the necessary network and/or UE resources. 
Depending on the positioning method to be used for locating the UE the internals of this procedure can be positioning 
method dependent. The procedure is completed with the end of the positioning measurements. 

Location Calculation and Release Procedure 

This generic procedure is initiated after the measurements are completed and is concerned with calculating the location 
of the UE and releasing all network and/or UE resources involved in the positioning. 
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9.1 Mobile Terminating Location Request 
9.1 .1 IVIT-LR routing procedure in PS and CS domain 
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Figure 9.1 : General Network Positioning for a MT-LR 

1) An external LCS client requests the current location of a target UE from a GMLC. The LCS Client may also 
request a deferred location request, i.e. based on event. The GMLC verifies the identity of the LCS client and its 
subscription to the LCS service requested and derives the MSISDN or IMSI of the target UE to be located and 
the LCS QoS from either subscription data or data supplied by the LCS client. For a call related location request, 
the GMLC obtains and authenticates the called party number of the LCS client. 

The LCS request may carry also the Service Identity and the Codeword. The GMLC may verify that the Service 
Identity received in the LCS request matches one of the service identities allowed for the LCS client. If the 
service identity does not match one of the service identities for the LCS client, the GMLC shall reject the LCS 
request. Otherwise, the GMLC can map the received service identity in a corresponding service type. 
If the GMLC supports the codeword mechanism and receives a codeword from a value added LCS client, the 
GMLC checks the target UE"s codeword handling information stored in the GMLC in order to know whether the 
target UE user wants to be protected by the codeword mechanism or not. If the codeword handling information 
indicates that the codeword shall be checked in the network, then the GMLC shall verify whether the Codeword 
received in the LCS request matches one of the target UE"s Codewords. If the codeword handling information 
indicates that the codeword shall be checked in the network but the GMLC does not store the list of Codewords 
for the target UE or the received Codeword does not match one of the Codewords for the target UE, the GMLC 
shall reject the LCS request. 

If the location request is originated by a Requestor, the Requestor Identity may be added to the LCS service 
request. LCS client should authenticate the Requestor Identity but this is outside the scope of this specification. 

For a session related location request, the GMLC obtains and authenticates the APN-NI of the LCS client. 

If location is required for more than one UE, or if periodic location is requested, the steps following below may 

be repeated. 

Note: This means that GMLC handles the periodicity of location requests as requested by the LCS client both in 

CS and PS domain. 

2) If the GMLC already knows both the VMSC/MSC server or SGSN location and IMSI for the particular 
MSISDN (e.g. from a previous location request), this step and step 3 may be skipped. Otherwise, the GMLC 
sends a SEND_ROUTING_INFO_FOR_LCS message to the home HLR/HSS of the target UE to be located 
with the IMSI or MSISDN of this UE. 

3) The HLR/HSS verifies that the calling party SCCP address of the GMLC corresponds to a known GSM/UMTS 
network element that is authorized to request UE location information. The HLR/HSS then returns one or several 
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of the addresses, the current SGSN and/or VMSC/MSC server and whichever of the IMSI and MSISDN was not 
provided in step (2) for the particular UE. 

Note: HLR/HSS may prioritize between the MSCA^LR or SGSN address sent to GMLC. The prioritisation 
might be based on information received from SGSN and/or MSC/VLR concerning the UE"s capabihties for 
LCS. Other priority criteria are for further study. 

4) In case GMLC receives only the MSC/VLR address, the MT LR proceeds as the CS-MT-LR procedure 
described in 9.L2. In case GMLC receives only the SGSN address, the MT LR proceeds as the PS-MT-LR 
procedure described in 9.L6. In case the GMLC receives several of the following addresses, SGSN, VMSC 
and/or MSC Server, it has to decide where to send the location request. If the requested MT-LR is known to be 
associated with a CS call, the CS-MT-LR procedure shall be invoked. If the requested MT-LR is associated with 
a PS session, the PS-MT-LR procedure only shall be invoked. Otherwise, both CS-MT-LR and PS-MT-LR are 
applicable. If LCS Client indicated deferred location request, GMLC shall indicate this together with applicable 
event type (ex. MS available) in requested PS/CS-MT-LR, see 9.1.8. 

NOTE: The order in which these procedures are invoked and whether one or both procedures are used may 

depend on subscription information for the LCS client, possible priority information returned by the HSS 
or information already stored in the GMLC (e.g. obtained from previous location requests). 

5) GMLC sends the location service response to the LCS client. If the LCS client requires it, the GMLC may first 
transform the universal location co-ordinates provided by the SGSN or MSC/MSC server into some local 
geographic system. The GMLC may record billing for both the LCS client and inter-network revenue charges 
from the SGSN or MSC/MSC server's network. The LCS Service Response from the GMLC to the LCS client 
may contain the information about the positioning method used. 

The detailed CS-MT-LR and PS-MT-LR procedures in step 4 of figure 9.1 are described in 9.1.2 and 9.1.6. 

The detailed procedure for deferred PS/CS-MT-LR is described in 9.1.8. 
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9.1 .2 Circuit Switclned Mobile Terminating Location Request (CS-MT-LR) 

Figure 9.2 illustrates general network positioning for LCS clients external to the PLMN. In this scenario, it is assumed 
that the target UE is identified using either an MSISDN or IMSI. 
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Figure 9.2: Network Positioning for a CS-I\/IT-LR 
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9.1.2.1 Location Preparation Procedure 

1) Common PS and CS MT-LR procedure as described in 9.1.1. 

2) The GMLC sends a PROVIDE. SUBSCRIBER .LOCATION message to the MSC/MSC server indicated by 
the HLR/HSS. This message carries the type of location information requested (e.g. current location), the UE 
subscriber's IMSI, LCS QoS information (e.g. accuracy, response time) and an indication of whether the LCS 
client has the override capability. For a call related location request, the message also carries the LCS client's 
called party number. For a value added LCS client, the message shall carry the client name, the external identity 
of the LCS client and the Requestor Identity (if that is both supported and available). For a PLMN operator LCS 
client, the message shall carry the internal identity of the LCS client. Moreover the message may also carry the 
Service Type. If the target UE"s codeword handling information indicates that the codeword shall be sent to the 
UE user for checking, the message may carry also the codeword received from the LCS client. For a PLMN 
operator LCS client, the message shall carry the internal identity of the LCS client. If the Requestor Identity is 
provided, the GMLC shall send it as separate information. In addition, in order to display the requestor identity 
in case of pre rel-5 network elements (i.e. MSC and/or UE), the requestor identity may be also added to the LCS 
client name by the GMLC. When the Requestor identity is added to the LCS client name the practise described 
in the Annex C should be followed. 

3) If the GMLC is located in another PLMN or another country, the VMSC/MSC server first authenticates that a 
location request is allowed from this PLMN or from this country. If not, an error response is returned. The 
VMSC/MSC server then verifies LCS barring restrictions in the UE user's subscription profile in the MSC 
server. In verifying the barring restrictions, barring of the whole location request is assumed if any part of it is 
barred or any requisite condition is not satisfied. If LCS is to be barred without notifying the target UE and a 
LCS client accessing a GMLC in the same country does not have the override capability, an error response is 
returned to the GMLC. Otherwise, if the UE is in idle mode, the Core Network performs paging, authentication 
and ciphering. The MSC will page a GPRS attached UE either through A/Iu or Gs interface, depending on the 
presence of the Gs interface (see Note). The UE will inform the network about its LCS capabilities, as described 
in chapter 6.3.4.. If the UE is instead in dedicated mode, the VMSC/MSC server will already have UE classmark 
information. In GSM this is supported by controlled early classmark sending. 

[Note 1 : In GSM, if the target UE has an established circuit call other than speech, the location request may be 
denied and an error response is then returned to the GMLC. If the location request is allowed for a non- 
speech circuit call, it shall be up to RAN to decide, on the basis of the applicable position methods and 
requested QoS, whether positioning is possible. This is FES] 

Note: In some network mode of operation, a GPRS capable UE may not receive the CS paging. In addition, 
upon receipt of a CS paging, a GPRS capable UE may immediately answer to the Paging Request or 
delay the answer, as defined in 3GPP TS 22.060 and 23.060. A GPRS UE in class B mode may also 
suspend its GPRS traffic, sending a GPRS Suspension Request to the network. 

4) If the location request comes from a value added LCS client and the UE subscription profile indicates that the 
UE must either be notified or notified with privacy verification and the UE supports notification of LCS 
(according to the UE Capability information), an LCS Location Notification Invoke message is sent to the target 
UE indicating the type of location request (e.g. current location) and the identity of the LCS client, the Requestor 
Identity (if that is both supported and available) and whether privacy verification is required. Moreover, the 
message may carry also the service type and the codeword. 

[FES: For a call related location request, the LCS client identity shall be set to the LCS client's called party 
number if no separate LCS client identity was received from the GMLC] Optionally, the VMSC/MSC server 
may after sending the LCS Location Notification Invoke message continue in parallel the location process, i.e. 
continue to step 6 without waiting for a LCS Location Notification Return Result message in step 5. 

NOTE 2: This step is for further study, it should be investigated e.g. which client identities to include in the Privacy 
Notification message to be shown to the end-user. 

5) The target UE notifies the UE user of the location request. If privacy verification was requested, the target UE 
indicates to the UE user whether the location request will be allowed or not allowed in the absence of a response 
and waits for the user to grant or withhold permission. The UE then returns an LCS Location Notification Return 
Result to the VMSC/MSC server indicating, if privacy verification was requested, whether permission is granted 
or denied. Optionally, the LCS Location Notification Return Result message can be returned some time after 
step 4, but before step 9. If the UE user does not respond after a predetermined time period, the VMSC/MSC 
server shall infer a "no response" condition. The VMSC/MSC server shall return an error response to the GMLC 
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if privacy verification was requested and either the UE user denies permission or there is no response with the 
UE subscription profile indicating barring of the location request in the absence of a response. 

6) The MSC/MSC server sends a Location Request message to RAN. This message includes the type of location 
information requested and requested QoS and, in GSM, the UE's location capabilities. 

9.1 .2.2 Positioning Measurement Establishment Procedure 

7) RAN determines the positioning method and instigates the particular message sequence for this method, as 
specified in UTRAN Stage 2, TS 25.305 [1] and GERAN Stage 2, TS 43.059 [16]. 

9.1 .2.3 Location Calculation and Release Procedure 

8) When a location estimate best satisfying the requested QoS has been obtained, RAN returns it to the MSC/MSC 
server in a Location Report message. The information about the positioning method used may be returned with 
the location estimate. If a location estimate could not be obtained, RAN returns a Location Report message 
containing a failure cause and no location estimate. 

9) The MSC/MSC server returns the location information and its age to the GMLC, if the VMSC/MSC server has 
not initiated the Privacy Verification process in step 4. If step 4 has been performed for privacy verification, the 
VMSC/MSC server returns the location information, only if it has received a LCS Location Notification Return 
Result indicating that permission is granted. In these cases, the information about the positioning method used 
may be sent with the location information. If a LCS Location Notification Return Result message indicating that 
permission is not granted is received, or there is no response, with the UE subscription profile indicating barring 
of location in the absence of a response, the VMSC/MSC server shall return an error response to the GMLC. If 
RAN did not return a successful location estimate, but the privacy checks in steps 4-5 were successfully 
executed, the VMSC/MSC server may return the last known location of the target UE if this is known and the 
LCS client is requesting the current or last known location. The MSC server may then release the Mobility 
Management connection to the UE, if the UE was previously idle, and the MSC/MSC server may record billing 
information. 

10)The GMLC returns the UE location estimate to the requesting LCS client as described in chapter 9.1.1. The LCS 
Service Response from the GMLC to the LCS client may contain the information about the positioning method 
used. 

9.1 .3 CS-MT-LR without HLR Query - applicable to North America 
Emergency Calls only 

Figure 9.3 illustrates current or last known location requests for a North American Emergency Services call, where an 
emergency services client (i.e., a Public Safety Answering Point) identifies the target UE and the serving GMLC using 
either an NA-ESRK, or an MSISDN and NA-ESRD that were previously provided to it by the VMSC. This allows the 
GMLC to request location from the VMSC without first querying the home HLR of the target UE. This scenario 
presumes that the initial location, as well as UE and VMSC identifying information had been pushed to the GMLC as 
per [32]. 
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Figure 9.3: Positioning for a Emergency Services lUIT-LR without IHLR Query 

1) Same as step 1 in figure 9.1 but with the LCS client identifying first the target UE and the serving GMLC by an 
- NA-ESRK or MSISDN and NA-ESRD. 

2) If the GMLC already has stored information for the target UE (e.g. from a prior location estimate delivery to the 
LCS client), the GMLC may determine the VMSC from this information. Otherwise, the GMLC determines the 
VMSC using the NA-ESRK or NA-ESRD - with use of the NA-ESRK taking priority over that of the 
NA-ESRD. The MAP_PROVIDE_SUBSCRIBER_LOCATION message sent to the VMSC carries the 
MSISDN and, if provided, the IMSI and IMEI for the target UE, as well as the required QoS and an indication of 
a location request from an emergency services client. The VMSC identifies the target UE using the IMSI or 
MSISDN and, if provided, the IMEI. In the case of a SIM-less UE making the emergency call, the MSISDN 
will have been populated with a non-dialable callback number, as specified in clause 6.4.3. 

3) The MSC verifies that UE privacy is overridden by the emergency services provider and that positioning is not 
prevented for other reasons (e.g. unreachable UE, inapplicable call type to the UE). The VMSC then sends a 
Location Request to the RAN, as for a normal MT-LR. 

4) RAN performs positioning as for a normal CS-MT-LR. 

5) RAN returns a location estimate to the VMSC as for a normal CS-MT-LR. 

6) Same as step 9 for a normal CS-MT-LR. 

7) Same as step 10 for a normal CS-MT-LR. 

9.1 .4 CS-MT-LR and PS-MT-LR for a previously obtained location 
estimate 

Every time the location estimate of a target UE subscriber is returned by the RAN to the VMSC, MSC Server or SGSN, 
the corresponding entity may store the location estimate together with a time stamp. The MSC/MSC server may store 
this information in the subscriber's MSC server record. 

The time stamp is the time at which the location estimate is stored at the corresponding entity i.e. after the RAN returns 
the location estimate to the VMSC, MSC Server or SGSN. The time stamp indicates the "age" of the location estimate. 
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9.1.4.1 Initial Location 

In the context of an originating emergency call the location estimate and the associated time stamp at the 
commencement of the call set-up is referred to as "initial location". 

9.1.4.2 Current Location 

After a location attempt has successfully delivered a location estimate and its associated time stamp, the location 
estimate and time stamp is referred to as the "current location" at that point in time. 

9.1 .4.3 Last known Location 

The current location estimate and its associated time stamp are stored in MSC/VLR, MSC Server or SGSN and until 
replaced by a later location estimate and a new time stamp is referred to as the "last known location ". The last known 
location may be distinct from the initial location - i.e. more recent. 

9.1 .4.4 Security and Privacy 

The handling of security and privacy of the target UE with regard to returning the last known or initial location estimate 
of the target UE shall be the same as when the target UE is reachable for positioning, (i.e. the requesting LCS client is 
authorized and the privacy of the target UE is secured before the VMSC/MSC server check the MSC server status of the 
target UE (i.e. whether the UE is marked as attached or detached in the MSC server). A similar status check apply for 
SGSN and MSC Server. 

9.1 .4.5 Failing to locate the target UE 

In case of a "Detached" or "Not Reachable" target UE, the last known location and a time stamp stored at the VLR, 
MSC Server or SGSN, may be returned to a LCS client requesting location information if the LCS client specifically 
requested the current or last known location. This does not apply to a value added LCS client where the target UE 
subscribes to notification of the location request: if the notification cannot be performed, the VMSC, MSC Server or 
SGSN shall reject the location request. 

NOTE: Due to CAMEL, the MSC/MSC server/VLR may already be storing other location information 

parameters like location number, service area identity and MSC server number in the subscriber's MSC 
server record. 

When a request for location information is received at the VMSC, MSC Server or SGSN, the request shall indicate 
whether the "last known location of the target UE" should be returned in case of a "detached" or "not reachable" target 
UE. 

If the VLR, MSC Server or SGSN has a valid copy of the subscriber's permanent data and the target UE's privacy 
settings are such that positioning is allowed, then the following two cases can occur. 

9.1 .4.5.1 Target UE is "Not Reachable" 

If the target UE is marked as "attached" in the VLR, MSC Server or SGSN, the corresponding entity orders paging of 
the target UE. If paging fails, due to target UE being "not reachable" then the corresponding VMSC, MSC Server or 
SGSN shall check whether the LCS client has requested "last known location" in case of "not reachable" target UE. 

If such a request exists and notification to the target UE does not apply for a value added LCS client, the VMSC, MSC 
Server or SGSN shall include the last known location together with the time stamp available in its response to the 
request for location information. 

An indicator of "last known location" returned shall be marked at the CDR at VMSC, MSC Server or SGSN 
correspondingly. 

9.1 .4.5.2 Target UE is "Detached" 

If the target UE is marked as "detached" in the VLR, MSC Server or SGSN, the corresponding entity shall check 
whether the LCS client has requested "last known location" in case of "detached" target UE. 
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If such a request exists and notification to the target UE does not apply for a value added LCS client, the VMSC, MSC 
Server or SGSN includes the "last known location" together with the time stamp available in its response to the request 
for location information. 

An indicator of "last known location" returned shall be marked at the CDR at VMSC, MSC Server or SGSN. 



9.1.4.5.3 



Target UE is Reachable but Positioning Fails 



If the target UE is reachable (e.g. paging succeeds), but the VMSC, MSC Server or SGSN is unable to obtain a current 
location estimate, then the corresponding entity shall check whether the LCS client has requested "last known location". 

If such a request exists and notification to the target UE either does not apply or was successfully executed for a value 
added LCS client, the VMSC, MSC Server or SGSN includes the "last known location" together with the time stamp 
available in its response to the request for location information. An indicator of "last known location" returned shall be 
marked at the CDR at VMSC. 

9.1 .4.5.4 MSC Server or SGSN.Target UE is "Purged" 

If the target UE is marked as "Purged" in HLR/HSS, then an indication "Absent Subscriber" is returned to the GMLC. 

9.1 .5 Network Induced Location Request (NI-LR) 

Figure 9.4 illustrates positioning for an emergency service call. 
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Figure 9.4: Positioning for a NI-LR Emergency Service Call 
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9.1.5.1 Location Preparation Procedure 

1) An initially idle UE requests radio connection setup indicating a request for an Emergency Service call to the 
VMSC/MSC server via RAN. 

2) RAN shall convey the CM service request to the core network. (Before having a CM connection there must be a 
radio connection.) The UE may identify itself using a TMSI, IMSI or IMEI. 

3) The emergency call procedure is applied. The VMSC/MSC server determines based on the serving cell the 
appropriate emergency services client. The VMSC/MSC server, RAN and UE continue the normal procedure for 
emergency call origination towards that emergency services client. Depending on local regulatory requirements, 
the sending of call setup information into the PSTN may be delayed until either the UE's location has been 
obtained or the location attempt has failed or a PLMN defined timer has expired before location was obtained. If 
the serving cell serves an area that contains the service domain of multiple emergency services clients, the 
VMSC/MSC server may delay call setup and invoke location based routing procedures described in section 

9. 1.5 A. Call setup information sent into the PSTN may include the UE location (if already obtained) plus 
information that will enable the emergency service provider to request UE location at a later time (e.g. NA- 
ESRD or NA-ESRK in North America). 

4) At any time after step 2, the VMSC/MSC server may initiate procedures to obtain the UE's location. These 
procedures may run either in parallel with the emergency call origination. The VMSC/MSC server sends a 
Location Request message to RAN associated with the UE's current location area (see step 6 for a MT-LR). This 
message includes the QoS required for an emergency call. 

9.1 .5.2 Positioning Measurement Establishment Procedure 

5) RAN determines the positioning method and instigates the particular message sequence for this method, as 
specified in UTRAN Stage 2, TS 25.305 [1] and GERAN Stage 2, TS 43.059 [16]. 

9.1 .5.3 Location Calculation and Release Procedure 

6) When a location estimate best satisfying the requested QoS has been obtained, RAN returns it to the 
VMSC/MSC server in a Location Report. The information of the positioning method used may be returned with 
the location estimate. If a location estimate could not be obtained, the RAN returns a location response 
containing a failure cause and no location estimate. 

7) Depending on local regulatory requirements, the VMSC/MSC server may send a MAP Subscriber Location 
report to a GMLC associated with the emergency services provider to which the emergency call has been or will 
be sent. This message shall carry any location estimate returned in step 6, the age of this estimate and may carry 
the MSISDN, IMSI and IMEI of the calling UE, and the information about the positioning method used. In the 
case of a SIM-less UE making the emergency call, the MSISDN may be populated with a non-dialable callback 
number depending on national or regional regulations, as specified in clause 6.4.3. In North America, any NA- 
ESRD and any NA-ESRK that may have been assigned by the VMSC/MSC server shall be included. The 
message shall also indicate the event that triggered the location report. If location failed (i.e. an error result was 
returned by RAN in step 6), an indication of failure rather than a location estimate may be sent to the GMLC: the 
indication of failure is conveyed by not including a location estimate in the MAP Subscriber Location Report. 

8) The GMLC acknowledges receipt of the location information. For a North American Emergency Services call, 
the GMLC shall store the location information for later retrieval by the emergency services LCS client. 

9) The GMLC may optionally forward the information received in step 8 to the emergency services LCS client. For 
a North American emergency services call the client is expected to obtain the location information by requesting 
it from the GMLC. The information about the positioning method used may be sent with the location 
information from the GMLC to the LCS client. 

10) At some later time, the emergency services call is released. 

1 l)For a North American Emergency Services call, the MSC/MSC server sends another MAP Subscriber Location 
Report to the GMLC. This message may include the same parameters as before except that there is no position 
estimate and an indication of emergency call termination is included. 

12)The GMLC acknowledges the MSC/MSC server notification and may then release all information previously 
stored for the emergency call. 
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Editorial Note: The procedure for Network Induced Location Request (NI-LR and PS-NI-LR) for a Target UE in 

dedicated mode should be defined in UTRAN system stage 2 [1] and GERAN Stage 2 specifications [16]. 

9.1 .5A NI-LR using Location Based Routing - applicable to North American 
Emergency Calls only 

Figure 9.4A illustrates positioning for an emergency service call using location based routing. 



Client 



GMLC 



9. Request for Locatii 
Information 



k 



15. Location Infomiaticn 



VMSC/ 
MSC SERVER 



6. MAP Subscriber Location Report 



7. MAP Subscriber Location Report ack 



8. Emergency Call Origination 



10. Provide Subscriber Location 



14. Provide Subscriber Location ack 



16. Emergency Call Release 



17. MAP Subscriber Location Report 



18. MAP Subscriber Location Report ack 



RAN 



UE 



2. (CM Service Request) 



3. Location Request 



4. N [essages for individual positioning metho ds 



5. Location Report 



11. Location Request 



1. CM Sei-vice Request 



12. Messages for individual positioning methods 



13. Location Report 



Figure 9.4A: Positioning for a NI-LR Emergency Service Call using Location Based Routing 
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9.1.5A.1 Location Preparation Procedure 

1) An initially idle UE requests radio connection setup indicating a request for an Emergency Service call to the 
VMSC/MSC server via RAN. 

2) RAN shall convey the CM service request to the core network. (Before having a CM connection there must be a 
radio connection.) The UE may identify itself using a TMSI, IMSI or IMEI. 

3) The VMSC/MSC server determines that the serving cell serves an area that contains portions of multiple 
emergency services zones. Therefore, the VMSC/MSC server delays call setup and initiates procedures to obtain 
the UE's location for routing the emergency call to the emergency services LCS client. The VMSC/MSC server 
sends a Location Request message to RAN associated with the UE's current location area. This message includes 
the type of location information requested, the UE"s location capabilities and a QoS with low delay and low 
horizontal accuracy. 

9.1 .5A.2 Positioning Measurement Establishment Procedure 

4) RAN determines the positioning method and instigates the particular message sequence for this method, as 
specified in UTRAN Stage 2, TS 25.305 [1] and GERAN Stage 2, TS 43.059 [16]. 

9.1 .5A.3 Location Calculation and Release Procedure 

5) When a location estimate best satisfying the requested QoS has been obtained, RAN returns it to the 
VMSC/MSC server. If a location estimate could not be obtained, the RAN returns a location response containing 
a failure cause and no location estimate. If a failure is received, the VMSC/MSC server initiates emergency call 
setup using the normal NI-LR procedures. 

6) The VMSC/MSC server sends a MAP Subscriber Location Report to a GMLC associated with the emergency 
services client to which the emergency call will be sent. This message shall carry any location estimate returned 
in step 5, the age of this estimate and may carry the MSISDN, IMSI and IMEI of the calling UE and the 
information about the positioning method used. In the case of a SIM-less UE making the emergency call, the 
MSISDN may be populated with a non-dialable callback number, as specified in clause 6.4.3. The message shall 
also indicate the event that triggered the location report. Any NA-ESRD and NA-ESRK that was assigned by the 
VMSC/MSC server shall be included. The message shall also include a request for an NA-ESRK value based on 
the UE position. 

7) The GMLC translates the location estimate into a zone identity and assigns a NA-ESRK, which was requested 
by the VMSC/MSC server. The GMLC shall include the NA-ESRK value in the MAP Subscriber Location 
Report ack and send it to the VMSC/MSC server. The GMLC stores the assigned NA- ESRK and any NA- 
ESRD that was sent by the VMSC/MSC server in step 6. 

9.1.5A.4 Location Preparation Procedure 

8) The emergency call procedure is applied. The VMSC/MSC server, RAN and UE continue the normal procedure 
for emergency call origination towards the appropriate emergency services client. Call setup information sent 
into the PSTN may include the UE location plus information that will enable the emergency service provider to 
request UE location at a later time (NA-ESRD or NA-ESRK in North America). The NA-ESRK used shall be 
the one received from the GMLC. If a NA-ESRK is not received from the GMLC then the VMSC/MSC server 
shall use the default NA-ESRK for the call as in 9.1.5.1 step 3. 

9) At any time after step 8, the emergency services LCS client may request location information. 

10) At any time after step 6, the GMLC may send a MAP Provide Subscriber Location message to the VMSC/MSC 
server. This message includes a QoS with higher delay and higher horizontal accuracy required for an emergency 
call. In the case of a SIM-less UE making the emergency call, the MSISDN may be populated with a non- 
dialable callback number, as specified in clause 6.4.3. 

If the GMLC is capable of determining whether the initial location satisfies the higher accuracy requirements for 
an emergency call, then the GMLC may not need to request for a higher accuracy location. 

ll)The VMSC/MSC server sends a Location Request message to RAN. This message includes the type of location 
information requested, the UE"s location capabilities and requested higher accuracy QoS. 
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9.1 .5A.5 Positioning Measurement Establishment Procedure 

12) same as step 4. 

9.1 .5A.6 Location Calculation and Release Procedure 

13) same as step 5. 

14) The VMSC/MSC server returns the location information and its age and the information about the positioning 
method used to the GMLC. The GMLC shall replace the previously stored low accuracy location information 
with the higher accuracy information for later retrieval by the emergency services LCS client. 

15) The GMLC may forward the information received in the previous step to the emergency services LCS client. 
The client is expected to have requested this information from GMLC before. The information about the 
positioning method used may be sent with this location information from the GMLC to the LCS client. 

16) same as step 10 for normal Nl-LR. 

17) same as step 1 1 for normal Nl-LR. 

18) same as step 12 for normal Nl-LR. 
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9.1 .6 Packet Switched Mobile Terminating Location Request 
(PS-MT-LR) 

Figure 9.5 illustrates the general network positioning for LCS clients external to the PLMN for packet switched 
services. In this scenario, it is assumed that the target UE is identified using an MSISDN or IMSI. 
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Figure 9.5: General Network Positioning for Packet Switched MT-LR 

9.1.6.1 Location Preparation Procedure 

1) Common PS and CS MT-LR procedure as described in 9.1.1. 

2) GMLC sends a Provide Subscriber Location message to the SGSN indicated by the HLR/HSS. This message 
carries the type of location information requested (e.g. current location), the UE subscriber's IMSI, LCS QoS 
information (e.g. accuracy, response time) and an indication of whether the LCS client has the override 
capability. For a session related location request, the message also carries the APN-NI to which the user has 
established the session. For a value added LCS client, the message shall carry the client name, the external 
identity of the LCS client and the Requestor Identity (if that is both supported and available), optionally the 
message may also carry the Service Type. If the target UE"s codeword handling information indicates that the 
codeword shall be sent to the UE user for checking, the message may carry also the codeword received from the 
LCS client. For a PLMN operator LCS client, the message shall carry the internal identity of the LCS client. If 
the Requestor Identity is provided, the GMLC shall send it as separate information. In addition, in order to 
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display the requestor identity in case of pre rel-5 network elements (i.e. SGSN and/or UE), the requestor identity 
may be also added to the LCS client name by the GMLC. When the Requestor identity is added to the LCS client 
name the practise described in the Annex C should be followed. 

3) If the GMLC is located in another PLMN or another country, the SGSN first authenticates that a location request 
is allowed from this PLMN or from this country. If not, an error response is returned. The SGSN then verifies 
LCS barring restrictions in the UE user's subscription profile in the SGSN. In verifying the barring restrictions, 
barring of the whole location request is assumed if any part of it is barred or any requisite condition is not 
satisfied. If LCS is to be barred without notifying the target UE and a LCS client accessing a GMLC in the same 
country does not have the override capability, an error response is returned to the GMLC. 

Otherwise, if the UE is in idle mode, the SGSN performs paging. The paging procedure is defined in TS 
23.060[I5]. 

FES: The UE may be paged for location services even when in UMTS a signaling connection between 
mobile station and the network is established and in GSM when in Ready Mode. This makes it possible 
for the UE to start preparing an anticipated location service coming later by e.g. starting to measure GPS 
signals. 

4) Security functions may be executed. These procedures are defined in TS 23.060 [15]. 

5) If the location request comes from a value added LCS client and the UE subscription profile indicates that the 
UE must either be notified or notified with privacy verification and the UE supports notification of LCS, a 
notification invoke message is sent to the target UE indicating the type of location request (e.g. current location) 
and the identity of the LCS client and the Requestor Identity (if that is both supported and available), whether 
privacy verification is required. Moreover, the message may carry also the service type and the codeword. 
Optionally, the SGSN may after sending the LCS Location Notification Invoke message continue in parallel the 
location process, i.e. continue to step 7 without waiting for a LCS Location Notification Return Result message 
in step 6. 

6) The target UE notifies the UE user of the location request and, if privacy verification was requested, waits for the 
user to grant or withhold permission. The UE then returns a notification result to the SGSN indicating, if privacy 
verification was requested, whether permission is granted or denied. Optionally, this message can be returned 
some time after step 5, but before step 10. If the UE user does not respond after a predetermined time period, the 
SGSN shall infer a "no response" condition. The SGSN shall return an error response to the GMLC if privacy 
verification was requested and either the UE user denies permission or there is no response with the UE 
subscription profile indicating barring of the location request. 

7) The SGSN sends a Location Request message to the RAN. This message includes the type of location 
information requested, the requested QoS and any other location information received in paging response. 

9.1 .6.2 Positioning Measurement Establishment Procedure 

8) If the requested location information and the location accuracy within the QoS can be satisfied based on 
parameters received from the SGSN and the parameters obtained by the RAN e.g. cell coverage and timing 
information (i.e. RTT or TA), the RAN may send a Location Report immediately. Otherwise, the RAN 
determines the positioning method and instigates the particular message sequence for this method in UTRAN 
Stage 2 TS 25.305 and in GERAN Stage 2 TS 43.059. If the position method returns position measurements, the 
RAN uses them to compute a location estimate. If there has been a failure to obtain position measurements, the 
RAN may use the current cell information and, if available, RTT or TA value to derive an approximate location 
estimate. If an already computed location estimate is returned for an UE based position method, the RAN may 
verify consistency with the current cell and, if available, RTT or TA. If the location estimate so obtained does 
not satisfy the requested accuracy and sufficient response time still remains, the RAN may instigate a further 
location attempt using the same or a different position method. If a vertical location co-ordinate is requested but 
the RAN can only obtain horizontal co-ordinates, these may be returned. 
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9.1.6.3 



Location Calculation and Release Procedure 



9) When location information best satisfying the requested location type and QoS has been obtained, the RAN 
returns it to the SGSN in a Location Report message. The information about the positioning method used may be 
returned with the location information. If a location estimate could not be obtained, the RAN returns a Location 
Report message containing a failure cause and no location estimate. 

10) The SGSN returns the location information and its age to the GMLC, if the SGSN has not initiated the Privacy 
Verification process in step 5. If step 5 has been performed for privacy verification, the SGSN returns the 
location information, only, if it has received a LCS Location Notification Return Result indicating that 
permission is granted. In these cases, the information about the positioning method used may be sent with the 
location information. If a LCS Location Notification Return Result message indicating that permission is not 
granted is received, or there is no response, with the UE subscription profile indicating barring of location, the 
SGSN shall return an error response to the GMLC. If the SGSN did not return a successful location estimate, but 
the privacy checks were successfully executed, the SGSN may return the last known location of the target UE if 
this is known and the LCS client is requesting the current or last known location. The SGSN may record billing 
information. 

1 l)The GMLC returns the UE location information to the requesting LCS client. If the LCS client requires it, the 
GMLC may first transform the universal location co-ordinates provided by the SGSN into some local geographic 
system. The GMLC may record billing for both the LCS client and inter-network revenue charges from the 
SGSN's network. The LCS Service Response from the GMLC to the LCS client may contain the information 
about the positioning method used. 

9.1 .7 Packet Switched Network Induced Location Request (PS-NI-LR) 

Figure 9.6 illustrates a network induced location request from the SGSN. This procedure may be used e.g. for 
positioning of an emergency call. 
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Figure 9.6: Network Induced Location Request 

1) The SGSN sends a Location Request message to the RAN. This message indicates the type of location 
information requested and requested QoS. 
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9.1 .7.1 Positioning IVIeasurement Establishment Procedure 

2) If the requested location information and the location accuracy within the QoS can be satisfied based on 
parameters received from the SGSN and the parameters obtained by the RAN e.g. cell coverage and timing 
information (i.e. RTT or TA), the RAN may send a Location Report immediately. Otherwise, the RAN 
determines the positioning method and instigates the particular message sequence for this method. If the position 
method returns position measurements, the RAN uses them to compute a location estimate. If there has been a 
failure to obtain position measurements, the RAN may use the current cell information and, if available, RTT or 
TA value to derive an approximate location estimate. If an already computed location estimate is returned for an 
UE based position method, the RAN may verify consistency with the current cell and, if available, RTT or TA 
value. If the location estimate so obtained does not satisfy the requested accuracy and sufficient response time 
still remains, the RAN may instigate a further location attempt using the same or a different position method. If a 
vertical location co-ordinate is requested but the RAN can only obtain horizontal co-ordinates, these may be 
returned. 

9.1 .7.2 Location Calculation and Release Procedure 

3) When a location estimate best satisfying the requested QoS has been obtained , the RAN returns a Location 
Report to the SGSN. This message carries the location estimate that was obtained. If a location estimate was not 
succesfully obtained , a failure cause is included in the Location Report. 

4) The SGSN shall send a MAP Subscriber Location Report to the GMLC obtained in step 1 carrying the MSISDN 
of the UE, the identity of the LCS client, the event causing the location estimate (NI-LR-PS) and the location 

estimate and its age. 

5) The GMLC shall acknowledge receipt of the location estimate provided that it serves the identified LCS client 
and the client is accessible. 

6) The GMLC may transfer the location information to the LCS client either immediately or upon request from the 
client. 

9.1 .8 Mobile Terminating Deferred Location Request 

Figure 9.6a illustrates the procedures for a Deferred Location Request, where the Location Report is returned based 
on a event. 
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Figure 9.6a: General Network Positioning for a Deferred MT-LR 



Deferred Location Request Procedure 



1) GMLC assigns a reference number to Provide Subscriber Location. Provide Subscriber Location is received in 
SGSN/MSC as described in 9.L2/9.L6. In addition, the Deferred Location Request includes the reference 
number and the event that shall trigger the sending of Location Report. 

Note: The GMLC shall send the Provide Subscriber Location for the UE regardless of the ongoing previous MT-LR 
for the same UE. 

2) If the SGSN/MSC cannot support the deferred location request for the specified event (for temporary or 
permanent reasons), a Provide Subscriber Location return error shall be returned in step 3 with a suitable 
cause. The SGSN/MSC verifies that the LCS client is allowed to position the requested UE according to 
subscription information (no interaction at this stage with the UE). If not, a Provide Subscriber Location return 
error is returned in step 3. 

3) If the SGSN/MSC can support the deferred location request for the specified event and the privacy checks in step 
2 are satisfied, a Provide Subscriber Location ack. shall be returned to the GMLC without a location estimate. 

4) The GMLC then returns the LCS Service Response to the LCS Client to notify whether the request was 
successfully accepted or not. The LDR reference number assigned by the GMLC shall be included in the 
response. 



9.1.8.2 



Location Report Procedure 



5) Immediately following step 3, the SGSN/MSC shall verify if the requested event is already satisfied (e.g. UE 
available inferred from a current transaction) or can be invoked immediately (e.g. by paging the UE and 
receiving a page response). If requested event is not existing the SGSN/MSC waits until it has occurred or until 
some maximum time has expired. 

=> In case the SGSN/MSC receives an indication that the UE has moved to another SGSN/MSC while it is waiting 
for the requested event to happen, a Subscriber Location Report is directly sent to the GMLC with the reference 
number that was included in the Provide Subscriber Location and the information that MT-LR must be re- 
initiated against the new SGSN/MSC. The adress of the new SGSN/MSC is included in Subscriber Location 
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Report if available. (If new SGSN/MSC adress was included, the GMLC continues at step 1 above, otherwise it 
continues with an interrogation against HLR as described in 9.1.1.) 

6) When the requested event is detected, the SGSN/MSC will proceed with the location request as described in 
9.1.2/9.1.6. 

If either security or privacy checks fails, a Subscriber Location Report with the reference number that was included 
in the Provide Subscriber Location is returned with appropriate error cause indicating termination of the deferred 
location request. 

7) When location information has been obtained from the RAN, the SGSN/MSC returns the Subscriber Location 
Report. The report shall include the reference number that was included in the Provide Subscriber Location and 
an indication that this is a response to a previously sent deferred location request. 

If the location information could not be obtained, or the SGSN/MSC for some other reason decides to not wait any 
longer for the requested event to occur (ex. timer expires), the Subscriber Location Report with the reference 
number that was included in the Provide Subscriber Location will be returned with an appropriate error cause 
indicating termination of the deferred location request. 

8) GMLC then returns the LCS Service Response to the LCS Client as in 9.1.2/9.1.6. The LDR reference number 
that was sent to the LCS Client in step 4 shall be included in the response. 

9.1.8.3 Combined Periodical/Deferred Mobile Terminating Location Request 

Figure 9.6b illustrates the procedures for a Combined Periodical/Deferred Mobile Terminating Location Request, 
where the response to the LCS client is returned periodically and based on the event. 

Note: In the current specification, it is assumed the LCS client issues the Periodical/Deferred MT-LR with only the 
location estimate type of 'current location'. 
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Figure 9.6b: General Network Positioning for a Combined Periodical/Deferred MT-LR 

1) When a GMLC receives a LCS Service Request from a LCS client, the GMLC verifies the identity of the LCS 
client as described in 9. 1 . 1 . 

2) The GMLC starts the periodical timer, sends a Send Routing Info for LCS to the home HLR/HSS of the target 
UE and gets SGSN/MSC addresses from the HLR/HSS as described in 9.1.1. 

3) The GMLC sends a Deferred Location Request to the SGSN/MSC by means of Provide Subscriber Location as 
described in 9.1.2/9.1.6. In addition, the Deferred Location Request includes the reference number assigned by 
the GMLC and the event that shall trigger the sending of Subscriber Location Report. 

Note: The GMLC shall send the Provide Subscriber Location for the UE regardless of the ongoing previous MT-LR 
for the same UE 

4) If the SGSN/MSC cannot support the deferred location request for the specified event or the LCS client is not 
allowed to position the requested UE according to subscription information, a Provide Subscriber Location error 
is returned to the GMLC. If the SGSN/MSC can support the deferred location request for the specified event and 
the privacy checks are satisfied, a Provide Subscriber Location ack shall be returned to the GMLC without a 
location estimate. 
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5) The GMLC then returns the LCS Service Response to the LCS Client to notify whether the request was 
successfully accepted or not. The LDR reference number assigned by the GMLC shall be included. 

6) When the periodical timer expires, if the GMLC is still waiting for the event, the GMLC shall send a LCS 
Service Response to the LCS client, indicating that the location is not available at that moment. The LDR 
reference number that was sent to the LCS Client in step 5 shall be included in the response. 

7) When the requested event is detected, the SGSN/MSC will proceed with the location request as described in 
9.1. 2/9. L6. 

8) When location information has been obtained from the RAN, the SGSN/MSC returns the Subscriber Location 
Report. The report shall include the reference number included in the previously sent Provide Subscriber 
Location and an indication that this is a response to a previously sent deferred location request. 

If the location information could not be obtained, or the SGSN/MSC for some other reason decides to not wait any 
longer for the requested event to occur (ex. timer expires), the Subscriber Location Report with the reference 
number included in the previously sent Provide Subscriber Location will be returned with an appropriate error 
cause indicating termination of the deferred location request. 

9) GMLC then returns the LCS Service Response to the LCS Client as in 9.L2/9.1.6. The LDR reference number 
that was sent to the LCS Client in step 5 shall be included in the response. 

10) When the timer expires, if the GMLC is not waiting for the event, the GMLC sends a Send Routing Info for LCS 
to the home HLR/HSS of the target UE and receives SGSN/MSC addresses from the HLR/HSS as described in 
9.1.1. The GMLC should use the same LDR reference number assigned in the step 3, should NOT assign a new 
LDR reference number. 

11) Same as step 3. 

12) Same as step 4. 

13) Same as step 5. 

14) If the requested event is already satisfied, the SGSN/MSC will proceed with the location request as described in 
9.1.2/9.1.6. 

15) Same as step 8. 

16) Same as step 9. 

9.1 .8.4 Cancellation of a Deferred Location Request 
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Figure 9.6c: Cancellation of a Deferred MT-LR procedure 

1) The LCS Client requests the cancellation of a previously requested Deferred Location Request. The LDR 

reference number that was included in the previous LCS Service Response sent by the GMLC shall be included 
in the request to indicate which outstanding LDR should be cancelled. The cancellation could be initiated by the 
GMLC itself for some reasons (e.g. implementation dependent timer in the GMLC expired, or the UE"s 
Codeword stored in the GMLC was changed and the Deferred Location Request is not allowed any more.). The 
event type to cancel must be indicated in the Cancellation procedure. 
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2) The GMLC will indicate this cancellation request in the Provide Subscriber Location toward the SGSN/MSC. 
The Provide Subscriber Location shall include the reference number specified by LCS Client in the LCS Cancel 
Service Request. 

3) When the SGSN/MSC completes the cancellation procedure, it notifies it to the GMLC in the Provide Subscriber 
Location Ack (with no location estimate included). 

4) The GMLC informs the LCS Client that the cancellation procedure has been successfully completed. 

9.2 Mobile Originating Location Request 

9.2.1 IVIobile Originating Location Request, Circuit Switclned (CS-IVIO-LR) 

The following procedure shown in figure 9.7 allows an UE to request either its own location, location assistance data or 
broadcast assistance data message ciphering keys from the network. Location assistance data may be used subsequently 
by the UE to compute its own location throughout an extended interval using a mobile based position method. The 
ciphering key enables the UE to decipher other location assistance data broadcast periodically by the network. The 
MO-LR after location update request may be used to request ciphering keys or GPS assistance data using the follow-on 
procedure described in TS 24.008 [24]. The procedure may also be used to enable an UE to request that its own location 
be sent to an external LCS client. 
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Figure 9.7: General Network Positioning for CS-IVIO-LR 
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9.2.1.1 Location Preparation Procedure 

1) If the UE is in idle mode, the UE requests a radio connection setup and sends a CM service request indicating a 
request for a call independent supplementary services to the VMSC/MSC server via RAN. 

2) RAN shall convey the CM service request to the core network. If the UE is in dedicated mode, the UE sends a 
CM Service Request on the already established radio connection. 

3) The VMSC/MSC server instigates authentication and ciphering if the UE was in idle mode or returns a Direct 
Transfer CM Service Accept if the UE was in dedicated mode. The UE will inform the network about its LCS 
capabilities, as described in chapter 6.3.4. 

4) The UE sends a LCS CS-MO-LR Location Services invoke to the VMSC/MSC server. Different types of 
location services can be requested: location of the UE, location of the UE to be sent to an external LCS client, 
location assistance data or broadcast assistance data message ciphering keys. If the UE is requesting its own 
location or that its own location be sent to an external LCS client, this message carries LCS requested QoS 
information (e.g. accuracy, response time). If the UE is requesting that its location be sent to an external LCS 
client, the message shall include the identity of the LCS client and may include the address of the GMLC 
through which the LCS client should be accessed. If a GMLC address is not included, the VMSC/MSC server 
may assign a GMLC address stored in the VMSC/MSC server. If a GMLC address is not available for this case, 
the VMSC/MSC server shall reject the location request. If the UE is instead requesting location assistance data 
or ciphering keys, the message specifies the type of assistance data or deciphering keys and the positioning 
method for which the assistance data or ciphering applies. The VMSC/MSC server verifies in the UE's 
subscription profile that the UE has permission to request its own location, request that its location be sent to an 
external LCS client or request location assistance data or deciphering keys (whichever applies). If the UE is 
requesting positioning and has an established call, the VMSC/MSC server may reject the request for certain non- 
speech call types. 

5) The VMSC/MSC server sends a Location Request message to RAN associated with the Target UE. The message 
indicates whether a location estimate or location assistance data is requested and, in GSM, includes the UE's 
location capabilities. If the UE's location is requested, the message also includes the requested QoS. If location 
assistance data is requested, the message carries the requested types of location assistance data. 

9.2.1 .2 Positioning Measurement Establishment Procedure 

6) If the UE is requesting its own location, RAN determines the positioning method and instigates the particular 
message sequence for this method, as specified in UTRAN Stage 2, TS 25.305 [1] and GERAN Stage 2, TS 
43.059 [16]. If the UE is instead requesting location assistance data, RAN transfers this data to the UE as 
described in subsequent clauses in TS 25.305 [1] and TS 43.059 [16] UE. 

9.2.1 .3 Location Calculation and Release Procedure 

7) When a location estimate best satisfying the requested QoS has been obtained or when the requested location 
assistance data has been transferred to the UE, RAN returns a Location Report to the VMSC/MSC server. This 
message carries the location estimate or ciphering keys if this was obtained. If a location estimate or deciphering 
keys were not successfully obtained or if the requested location assistance data could not be transferred 
successfully to the UE, a failure cause is included in the Location Report. 

8) If the UE requested transfer of its location to an external LCS client and a location estimate was successfully 
obtained, the VMSC/MSC server shall send a MAP Subscriber Location Report to the GMLC obtained in step 4 
carrying the MSISDN of the UE, the identity of the LCS client, the event causing the location estimate (CS-MO- 
LR) and the location estimate and its age. 

9) The GMLC shall acknowledge receipt of the location estimate provided that is serves the identified LCS cUent 
and the client is accessible. 

10) The GMLC transfers the location information to the LCS client. 

1 l)The VMSC/MSC server returns an CS-MO-LR Return Result to the UE carrying any location estimate requested 
by the UE, ciphering keys or a confirmation that a location estimate was successfully transferred to the GMLC 
serving an LCS client. 



£75/ 



3GPP TS 23.271 version 5.12.0 Release 5 



57 



ETSI TS 123 271 V5.12.0 (2004-09) 



12) The VMSC/MSC server may release the CM, MM and radio connections to the UE, if the UE was previously 
idle, and the VMSC/MSC server may record billing information. 

9.2.2 Mobile Originating Location Request, Pacl^et Switclned (PS-MO-LR) 

The following procedure shown in figure 9.8 allows an UE to request either its own location; location assistance data or 
broadcast assistance data message ciphering keys from the network. Location assistance data may be used subsequently 
by the UE to compute its own location throughout an extended interval using a mobile based position method. A 
ciphering key enables the UE to decipher other location assistance data broadcast periodically by the network. The 
PS-MO-LR may be used to request ciphering keys or GPS assistance data. The procedure may also be used to enable an 
UE to request that its own location be sent to an external LCS client. 
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Figure 9.8: General Network Positioning for packet switched MO-LR 



Location Preparation Procedure 



1) In UMTS, if the UE is in idle mode, the UE requests a PS signaling connection and sends a Service request 
indicating signaling to the SGSN via the RAN. If the UE already has PS signaling connection, the UE does not 
need to send Service request. Security functions may be executed. These procedures are described in 

TS 23.060 [15]. In GSM this signaling step is not needed. 

2) The UE sends a LCS PS-MO-LR Location Services invoke message to the SGSN. Different types of location 
services can be requested: location of the UE, location of the UE to be sent to an external LCS client, location 
assistance data or broadcast assistance data message ciphering keys. If the UE is requesting its own location or 
that its own location be sent to an external LCS client, this message carries LCS requested QoS information (e.g. 
accuracy, response time). If the UE is requesting that its location be sent to an external LCS client, the message 
shall include the identity of the LCS client and may include the address of the GMLC through which the LCS 
client should be accessed. If a GMLC address is not included, the SGSN may assign a GMLC address stored in 
the SGSN. If a GMLC address is not available for this case, the SGSN shall reject the location request. If the UE 
is instead requesting location assistance data or ciphering keys, the message specifies the type of assistance data 
or deciphering keys and the positioning method for which the assistance data or ciphering applies. The SGSN 
verifies the subscription profile of the UE and decides if the requested service is allowed or not. 
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3) The SGSN sends a Location Request message to the RAN associated with the Target UE's location. The message 
indicates whether a location estimate or location assistance data is requested. If the UE's location is requested, 
the message also includes the requested QoS. If location assistance data is requested, the message carries the 
requested types of location assistance data. The message carries also location parameters received in the Service 
Invoke message. 

9.2.2.2 Positioning Measurement Establishment Procedure 

4) If the UE is requesting its own location, the actions described in UTRAN Stage 2, TS 25.305 [1] or GERAN 
stage 2 TS 43.059 [16] are performed. If the UE is instead requesting location assistance data, the RAN transfers 
this data to the UE as described in subsequent clauses. The RAN determines the exact location assistance data to 
transfer according to the type of data specified by the UE, the UE location capabilities and the current cell. 

9.2.2.3 Location Calculation and Release Procedure 

5) When a location estimate best satisfying the requested QoS has been obtained or when the requested location 
assistance data has been transferred to the UE, the RAN returns a Location Report to the SGSN. This message 
carries the location estimate or ciphering keys if this was obtained. If a location estimate or deciphering keys 
were not successfully obtained or if the requested location assistance data could not be transferred successfully 
to the UE, a failure cause is included in the Location Report. 

6) If the UE requested transfer of its location to an external LCS client and a location estimate was successfully 
obtained, the SGSN shall send a MAP Subscriber Location Report to the GMLC obtained in step 2 carrying the 
MSISDN of the UE, the identity of the LCS client, the event causing the location estimate (MO-LR-PS) and the 
location estimate and its age. 

7) The GMLC shall acknowledge receipt of the location estimate provided that it serves the identified LCS client 
and the client is accessible. 

8) The GMLC transfers the location information to the LCS client. 

9) The SGSN returns a Service Response message to the UE carrying any location estimate requested by the UE, 
ciphering keys or a confirmation that a location estimate was successfully transferred to the GMLC serving an 
LCS cHent. 

NOTE: Steps 2-9 may be repeated a number of times in case of periodic location request. 

9.3 LCS signaling procedures specified in UTRAN and GERAN 
Stage 2 

The signaling procedures in UTRAN and GERAN are defined in TS 25.305 [1] and TS 43.059 [16] respectively. 



9.4 Exception Procedures 



The procedures in this clause apply to all variants of an MT-LR, NI-LR and MO-LR where a Location Request message 
has been sent to RAN requesting some location service (e.g. provision of a location estimate for a target UE or transfer 
of assistance data to a target UE). 
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9.4.1 Procedures in the VMSC, MSC server 

After the VMSC/ MSC server has requested a location service for a particular UE from RAN, certain events may occur 
that may temporarily or permanently interfere with the location service attempt. For each such event notified to the 
VMSC /MSC server, the VMSC /MSC server shall employ one of the following error recovery actions. 

Restart the Location Service 

This action shall be employed for any event that temporarily impedes a location service attempt and cannot be delayed 
until the location service attempt is complete. When such an event is notified to the VMSC /MSC server, it shall 
immediately cancel the location service attempt and the associated signaling dialogue with RAN, if this still exists by 
sending a "stop reporting" message to RAN. The "stop reporting" message shall contain the reason for the location 
procedure cancellation in A/Gb mode or the indication about the type of location request to cancel (e.g. direct) in lu 
mode. 

After aborting the location request dialogue with RAN, the VMSC /MSC server may queue the location service request 
until the event causing the restart has terminated (if not already terminated). The VMSC /MSC server may optionally 
wait for an additional time period (e.g. if the queuing delay is minimal) to ensure that any resources allocated in and by 
RAN have time to be released. The VMSC /MSC server may then send another location service request to RAN 
associated with the target UE. 

Abort the Location Service 

This action shall be employed for any event that permanently impedes a location service attempt, such as loss of the 
dedicated signaling channel to the target UE. When such an event is notified to the VMSC /MSC server, it shall cancel 
the current location service attempt and the associated signaling dialogue with RAN, if still existing, by sending a "stop 
reporting" message to RAN. The "stop reporting" message shall contain the reason for the location procedure 
cancellation in A/Gb mode or the indication about the type of location request to cancel (e.g. direct) in lu mode. The 
VMSC /MSC server shall then return an error response to the client or network entity from which the location request 
was originally received. The VMSC /MSC server shall also release all resources specifically allocated for the location 
attempt. 

The following table indicates the appropriate error recovery procedure for certain events. For events not listed in the 
table, the VMSC need take no action. 

Table 9.1 : LCS Error Recovery Procedures in the VMSC /MSC server for certain Events 



Event 


VMSC /MSC server Error Recovery 


Release of radio channel to the UE 


Abort 


Any error response from RAN, except for SRNC relocation or inter- 
MSC handover 


Abort 


In lu mode inter RNC hard handover, SRNC relocation and inter- 
MSC or MSC server handover 


Abort on lu level 

Restart after process is completed 


In A/Gb mode inter-IVISC Handover and inter-BSC handover 


Restart after handover is completed 


InterSystem handover 


Restart after handover is completed 



If RAN is in an overload condition, it may reject a location request by indicating congestion. The VMSC /MSC server 
may reduce the frequency of future location service requests until rejection due to overload has ceased. 

9.4.2 Void 

9.4.3 Procedures in tine SGSN 

After the SGSN has requested a location service for a particular UE from RAN, certain events may occur that may 
temporarily or permanently interfere with the location service attempt. For each such event notified to the SGSN, the 
SGSN shall employ one of the following error recovery actions. 

Restart the Location Service 

This action shall be employed for any event that temporarily impedes a location service attempt and cannot be delayed 
until the location service attempt is complete. When such an event is notified to the SGSN, it shall immediately cancel 
the location service attempt and the associated signaling dialogue with RAN, if this still exists by sending a "stop 



£75/ 



3GPP TS 23.271 version 5.12.0 Release 5 



60 



ETSI TS 123 271 V5.12.0 (2004-09) 



reporting" (lu mode) or "location abort" (A/Gb mode) message to RAN. The "stop reporting"/"location abort" message 
shall contain the reason for the location procedure cancellation. 

After aborting the location request dialogue with RAN, the SGSN may queue the location service request until the event 
causing the restart has terminated (if not already terminated). The SGSN may optionally wait for an additional time 
period (e.g. if the queuing delay is minimal) to ensure that any resources allocated in and by RAN have time to be 
released. The SGSN may then send another location service request to RAN associated with the target UE. 

Abort the Location Service 

This action shall be employed for any event that permanently impedes a location service attempt, such as loss of the 
radio channel to the target UE. When such an event is notified to the SGSN, it shall cancel the current location service 
attempt and the associated signaling dialogue with RAN, if still existing, by sending a "stop reporting"/"location abort" 
message to RAN. The "stop reporting"/"location abort" message shall contain the reason for the location procedure 
cancellation. The SGSN shall then return an error response to the client or network entity from which the location 
request was originally received. The SGSN shall also release all resources specifically allocated for the location 
attempt. 

The following table indicates the appropriate error recovery procedure for certain events. For events not listed in the 
table, the SGSN need take no action. 

Table 9.2: LCS Error Recovery Procedures in the SGSN for certain Events 



Event 


SGSN Error Recovery 


Release of radio channel to the UE 


Abort 


Any error response from RAN causing unavailable signalling 
connections 


Abort 


Inter RNC hard handover, Inter SRNC relocation (lu mode 
only) 


Abort on lu level 

Restart after process is completed 


Suspend of GPRS services (A/Gb mode only)(During OS 
connection for class B UE) 


Abort 


Intra SGSN Routing Area Update (A/Gb mode only) 


Restart 


Inter SGSN Routing Area Update, Inter SGSN relocation 


Abort (Note: GMLG may restart) 


Standalone P-TIVISI Reallocation (A/Gb mode only) 


Restart 



9.4.4 Procedures in the UE 



9.4.5 Handover handling 



9.4.5.1 



VMSC /MSC server procedure for Inter-VMSC /MSC server handover 



When a location estimate is required for a target UE with an established call in a state of inter- VMSC /MSC server 
handover, the serving location area ID shall be used by the visited MSC /MSC server to identify the correct RAN to 
serve the location request. All location request related messages shall be sent via MAP/E interface piggy-backed in 
MAP_FORWARD_ACCESS_SIGNALLING and MAP PROCESS_ACCESS_SIGNALLING between the visited and 
serving MSCs /MSC servers. 



9.4.5.2 



Handling of an ongoing handover while a request for positioning arrives 



If during an ongoing handover procedure a request for location information arrives, the request shall be suspended until 
the handover is completed. On completion of the handover, the location preparation procedure shall continue. 



9.4.5.3 



Handover handling in lu mode 



In case of hard handovers in lu mode, e.g. inter RNC hard handover, or Serving RNC relocation and inter- MSC, MSC 
Server or SGSN handovers, the ongoing positioning process is aborted on lu level. In soft handovers where the Serving 
RNS and lu are relocated, any ongoing positioning process is also aborted on lu level. The MSC, MSC Server or SGSN 
shall restart the lu aborted location requests with the new Serving RNC. The new SGSN, however, shall not restart the 
location request after inter SGSN Routing Area Update or inter SGSN relocation. During intra and inter RNC soft and 
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softer handovers the existing RRC connection can normally be used without any need to abort the on-going positioning 
process on lu level. 

9.5 Privacy 

9.5.1 Privacy Override Indicator (POI) 

The POI is used to determine whether the privacy settings of the subscriber to be positioned shall be overridden by the 
request for location services. The POI is applicable only to Emergency service and Lawful intercept service. The 
assignment of a POI value with an "override" or "not override" value in the LCS client profile is done during the LCS 
client provisioning. The type of LCS client requesting location information (i.e. emergency, law-enforcement etc.) shall 
determine the value of the POI assigned to the LCS client profile. 

There are two distinct cases regarding the handling of the privacy override indicator. 

Procedure A: If the subscriber to be positioned is in the same country as the GMLC or if the subscriber to be positioned 
is in a different country than the GMLC and an appropriate bilateral agreement exists between operators, then the POI 
shall override the subscriber's privacy options, as allowed by regulatory requirements. 

Procedure B: Otherwise the POI shall not override the subscriber's privacy options. 

9.5.2 Privacy Procedures 

The SLPP shall contain the privacy options defined in the HLR of the UE subscriber. 

The SLPP shall be downloaded to the VMSC, MSC Server and SGSN together with the rest of his subscription 
information in the existing operation INSERT_SUBSCRIBER_DATA. It will be deleted with the existing operation 
DELETE_SUBSCRIBER_DATA. 

The POI is transferred from the GMLC to the VMSC/MSC Server/SGSN in the location request. Based on the location 
of the GMLC the VMSC/MSC Server/SGSN evaluates whether to accept or ignore the received POI according to the 
definition in clause. 

If the POI is accepted the location requested is unconditionally performed. Otherwise if the POI is ignored the 
VMSC/MSC Server/SGSN evaluates the privacy options in the UE subscriber's subscription profile (assuming this is 
held in the VLR/MSC Server/SGSN). If the corresponding register does not contain the UE subscription profile, LCS 
will rely on the existing GSM recovery mechanisms to obtain the profile. 

If local regulatory requirements mandate it, any MT-LR for an emergency services LCS client and any NI-LR for an 
emergency services call origination shall be allowed by the VMSC/MSC Server. 

If the location request is allowed by the privacy options the location request is performed. Otherwise, if the location 
request is barred by the privacy options, the location request is refused an error response is returned to the GMLC with 
a cause code indicating that the request was rejected by the subscriber. 



9.5.3 UE Privacy Options 



The UE privacy options in the SLPP apply to an CS-MT-LR/PS-MT-LR or NI-LR/PS-NI-LR and either indicate that no 
CS-MT-LR/PS-MT-LR or NI-LR/PS-NI-LR is allowed for the UE (except as may be ovemdden by the POI or local 
regulatory requirements) or define the particular classes of LCS client for which an CS-MT-LR/PS-MT-LR or 
NI-LR/PS-NI-LR for location are allowed, with the following classes being possible: 

[Editor's note: An e-mail comment pointed out that there are different cases still to be covered in the description of 
the classes: L the LCS Client identity is included in SLPP or 2. the LCS Client identity is NOT included 
in SLPP. Also some GMLC restriction conditions need to be mentioned.] 

a) Universal Class - allow positioning by all LCS clients; 

b) Call/Session related Class 

c) Call/Session-unrelated Class 
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d) PLMN operator Class 

Moreover the SLPP may contain the service types allowed by the subscriber. 

All UE privacy options of above four classes are commonly used for both CS and PS domain. 

If more than one privacy class are subscribed, privacy class for an MT-LR is selected according to the rule described in 

the ANNEX A. ANNEX A applies also in case service types privacy checking are subscribed together with one or 

more other privacy classes. 

Note 1 : If a privacy option setting in a domain is updated, the same modification will be applied to the other domain. 

Note 2: The options for each privacy class and the service type are described in the subsequent chapters 

independently from the options of the other privacy classes. The combination of the privacy class and 
service type options are described in the rules of Annex A 

9.5.3.1 Universal class 

When the user of the UE subscribes to the "Universal Class" the CS-MT-LR/PS-MT-LR or NI-LR/PS-NI-LR 
positioning is allowed by all LCS clients. 

If the UE subscribes to the universal class, any CS-MT-LR or NI-LR shall be allowed by the VMSC/MSC Server and 
any PS-MT-LR or PS-NI-LR shall be allowed by the SGSN. 

9.5.3.2 Call/Session related class 

When the user of the UE subscribes to the "Call/Session related Class" the CS-MT-LR/PS-MT-LR or NI-LR/PS-NI-LR 
positioning is allowed in the following cases: 

Allow positioning by specific identified value added LCS client or groups of value added LCS Client to which the UE 
originated a call in CS domain or a value added LCS client with which the UE has a session via an active PDP context 
in PS domain indicated by a specific APN-NI. For each identified LCS client or group of LCS Clients, one of the 
following subscription options shall apply: 

* location request allowed only from GMLCs identified in the SLPP; 

* location request allowed only from a GMLC in the home country; 

* location request allowed from any GMLC (default case). 

For each identified value added LCS client or group of LCS Clients in the privacy exception list, one of the 
following subscription options shall apply: 

* positioning allowed without notifying the UE user (default case); 

* positioning allowed with notification to the UE user; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user or if there is no response to the notification; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user. 

For all value added LCS clients sending a call related CS-MT-LR/PS-MT-LR that are not identified in the 
privacy exception list, one of the following subscription option shall apply: 

* positioning not allowed; 

* positioning allowed without notifying the UE user (default case); 

* positioning allowed with notification to the UE user; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user or if there is no response to the notification; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user. 



£75/ 



3GPP TS 23.271 version 5.1 2.0 Release 5 63 ETSI TS 1 23 271 V5.1 2.0 (2004-09) 

9.5.3.2.1 Call/session-related class in the CS-domain 

If the UE subscribes to the call/session-related class, an CS-MT-LR may be allowed if both of following conditions are 
met: 

The UE previously originated a call in CS domain that is still established and the called party number dialled by 
the UE matches the called party number received from the GMLC. 

The identity of the LCS client or LCS client group supplied by the GMLC matches the identity of any LCS 
Client or LCS Client group contained in the UE"s SLPP and any other GMLC restrictions associated with this 
LCS Client identity in the SLPP are also met 

If these conditions are satisfied, the CS-MT-LR shall be allowed if the UE user subscribes to either location without 
notification or location with notification. If the UE user subscribes to location with notification and privacy verification, 
the CS-MT-LR shall be allowed following notification to the UE if the UE user either returns a response indicating that 
location is allowed or returns no response but subscribes to allowing location in the absence of a response. In all other 
cases, the CS-MT-LR shall be restricted. 

9.5.3.2.2 Call/session-related class in the PS-domain 

If the UE subscribes to the call/session-related class, a PS-MT-LR may be allowed if all of the following conditions are 

met: 

The UE previously originated a PDP-context towards the network where the external client is located and that 
this context is still established 

- The APN-NI negotiated between the UE and SGSN matches the APN-NI received from the GMLC. 

The identity of the LCS client or LCS client group supplied by the GMLC matches the identity of any LCS 
Client or LCS Client group contained in the UE"s SLPP and any other GMLC restrictions associated with this 
LCS Client identity in the SLPP are also met 

If these conditions are satisfied, the PS-MT-LR shall be allowed if the UE user subscribes to either location without 
notification or location with notification. If the UE user subscribes to location with notification and privacy verification, 
the PS-MT-LR shall be allowed following notification to the UE if the UE user either returns a response indicating that 
location is allowed or returns no response but subscribes to allowing location in the absence of a response. In all other 
cases, the PS-MT-LR shall be restricted. 

9.5.3.2.3 Call/session-related class when LCS client not in SLPP 

If the UE subscribes to the call/session related class, a CS-MT-LR or PS-MT-LR from an LCS client that is NOT 
contained in the SLPP of the target UE shall be allowed or restricted according to the following conditions: 

For any non-matched LCS client, the CS-MT-LR or PS-MT-LR shall be allowed, if the UE user subscribes to 
either location without notification or location with notification. 

If the UE user subscribes to location with notification and privacy verification, the CS-MT-LR or PS-MT-LR shall be 
allowed following notification to the UE if the UE user either returns a response indicating that location is allowed or 
returns no response but subscribes to location in the absence of a response. In all other cases, the CS-MT-LR or PS-MT- 
LR shall be restricted. 

9.5.3.3 Call/Session-unrelated class 

When the user of the UE subscribes to the "Call/Session unrelated Class" the CS-MT-LR/PS-MT-LR or NI-LR/PS-NI- 
LR positioning is allowed in the following cases: 

Allow positioning by specific identified value added LCS Clients or groups of value added LCS Client with the 
following restrictions allowed for each identified value added LCS Client or group of value added LCS Clients: 

* location request allowed only from GMLCs identified in the SLPP; 

* location request allowed only from a GMLC in the home country; 

* location request allowed from any GMLC (default case). 
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For each identified value added LCS client in the privacy exception list, one of the following subscription 
options shall apply: 

* positioning allowed without notifying the UE user (default case); 

* positioning allowed with notification to the UE user; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user or if there is no response to the notification; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user. 

For all value added LCS clients sending a non-call related CS-MT-LR/PS-MT-LR that are not identified in the 
privacy exception list, one of the following subscription option shall apply: 

* positioning not allowed (default case); 

* positioning allowed with notification to the UE user; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user or if there is no response to the notification; 

* positioning requires notification and verification by the UE user; positioning is allowed only if granted by the 
UE user. 

9.5.3.3.1 Call/session-unrelated class when LCS client identities match 

If the UE subscribes to the call/session-unrelated class, an CS-MT-LR/PS-MT-LR may be allowed by the MSC/MSC 
server or SGSN if the identity of the LCS client or LCS client group supplied by the GMLC matches the identity of any 
LCS Client or LCS Client group contained in the UE's SLPP and any other GMLC restrictions associated with this LCS 
Client identity in the SLPP are also met. 

If the LCS client is correctly matched in this way and any GMLC restrictions are satisfied, the CS-MT-LR/PS-MT-LR 
shall be allowed if the UE user subscribes to either location without notification or location with notification. If the UE 
user subscribes to location with notification and privacy verification, the CS-MT-LR/PS-MT-LR shall be allowed 
following notification to the UE if the UE user either returns a response indicating that location is allowed or returns no 
response but subscribes to location in the absence of a response. In all other cases, the CS-MT-LR/PS-MT-LR shall be 
restricted. 

9.5.3.3.2 Call/session-unrelated class when LCS client identities do not match 

If the UE subscribes to the call/session-unrelated class, an CS-MT-LR/PS-MT-LR from an LCS client that is not 
contained in the UE's SLPP shall be allowed or restricted according to the following conditions. For any non-matched 
LCS client, the CS-MT-LR/PS-MT-LR shall be allowed if the UE user subscribes to location with notification. If the 
UE user subscribes to location with notification and privacy verification, the CS-MT-LR/PS-MT-LR shall be allowed 
following notification to the UE if the UE user either returns a response indicating that location is allowed or returns no 
response but subscribes to location in the absence of a response. In all other cases, the CS-MT-LR/PS-MT-LR shall be 
restricted. 
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9.5.3.4 PLMN operator class 

When the user of the UE subscribes to the " PLMN operator Class" the CS-MT-LR/PS-MT-LR or NI-LR/PS-NI-LR 
positioning is allowed in the following cases: 

Allow positioning by specific types of client within or associated with the VPLMN, with the following types of client 
identified: 

* clients providing a location related broadcast service; 

* O&M chent in the HPLMN (when the UE is currently being served by the HPLMN); 

* O&M chent in the VPLMN; 

* clients recording anonymous location information without any UE identifier; 

* clients enhancing or supporting any supplementary service, IN service, bearer service or teleservice subscribed 
to by the target UE subscriber. 

If the UE subscribes to the PLMN class, an NI-LR/PS-NI-LR or CS-MT-LR/PS-MT-LR shall be allowed if the chent 
within the VPLMN, for an NI-LR/PS-NI-LR, or the client identified by the GMLC, for an CS-MT-LR/PS-MT-LR, 
either matches a generic type of client contained in the UE's SLPP or is otherwise authorized by local regulatory 
requirements to locate the UE. 

9.5.3.5 Service type checking 

If the SLPP contains service types, an CS-MT-LR/PS-MT-LR may be allowed by the MSC/MSC server or SGSN if the 
service type supplied by the GMLC matches the identity of any service type contained in the UE's SLPP and any other 
GMLC restrictions associated with this service type in the SLPP are also met. 

If the service type is correctly matched in this way and any GMLC restrictions are satisfied, the CS-MT-LR/PS-MT-LR 
shall be allowed if the UE user subscribes to either location without notification or location with notification. If the UE 
user subscribes to location with notification and privacy verification, the CS-MT-LR/PS-MT-LR shall be allowed 
following notification to the UE if the UE user either returns a response indicating that location is allowed or returns no 
response but subscribes to location in the absence of a response. In all other cases, the CS-MT-LR/PS-MT-LR shall be 
restricted. 

9.5.3.6 Matching of LCS client identities 

In evaluating privacy where any address "A" associated with the LCS client (e.g. LCS client ID or GMLC address) 
needs to be compared with a corresponding address "B" in the target UE's SLPP, a match shall be determined if a match 
is found for each of the following components of each address: 

a) numbering plan; 

b) nature of address indicator; 

c) corresponding address digits for all digits in "B" (the digits or initial digits in "A" must match all the digits in 
"B", but "A" may contain additional digits beyond those in "B"). 

All addresses shall be transferred to the MSC/VLR, MSC server or SGSN in international format, except for the called 
party number received from the GMLC during a Call-Related CS MT-LR when the LCS client was reached via IN or 
abbreviated number routing (e.g. toll-free number or emergency call routing). In these cases it is up to the GMLC to use 
the valid national specific number of the visited country. 

In evaluating privacy where an APN-NI associated with the LCS client notified by the GMLC needs to be compared 
with a corresponding APN-NI that is used to set up the associated PDP context, a match shall be determined if a match 
is found for each component of APN-NI. 



£75/ 



3GPP TS 23.271 version 5.1 2.0 Release 5 66 ETSI TS 1 23 271 V5.1 2.0 (2004-09) 

9.6 Mobile Originating Location 

An UE may subscribe to any of the following classes of mobile originating location: 

a) Basic Self Location; 

b) Autonomous Self Location; 

c) Transfer to Third Party. 

An MO-LR shall be allowed by the VMSC if the type of request is supported by the appropriate subscription according 
to the following table. 

Table 9.3: Required UE Subscription Options for IVIO-LR Requests 



Type of MO-LR Request 


Required UE Subscription 


UE requests own location 


Basic Self Location 


UE requests location assistance data 


Autonomous Self Location 


UE requests transfer of own location to another LCS Client 


Transfer to Third Party 



9.7 CIV! Procedures 

9.7.1 Location request for a mobile in idle-mode 

When a request for location information is received at the VMSC the LCS -layer shall order paging of the UE 
subscriber. In case of first unsuccessful paging, normal paging procedures should apply. After successful paging the 
LCS-layer shall invoke the location preparation procedure. 

9.7.2 Location request for a mobile in dedicated-mode 

When a request for location information is received at the VMSC, if the UE is already busy on CM level, the LCS-layer 
shall attempt to establish a parallel transaction to the existing one. If successful, the LCS-layer shall invoke the location 
preparation procedure. 



1 Information storage 

This clause describes information storage structures that are mandatory (M), conditional (C) or optional (O) for LCS, 
and the recovery and restoration procedures needed to maintain service if inconsistencies in databases occur and for lost 
or invalid database information. Information storage in RAN network elements is specified in UTRAN Stage 2 
(TS 25.305 [1]) and GERAN Stage 2 (TS 43.059 [16]) specifications. 

10.1 HLRanclHSS 

The HLR/HSS holds LCS data for both UE subscribers and LMUs. 

1 0.1 .1 LCS Data in the HLR/HSS for an UE Subscriber 

The IMSI is the primary key for LCS UE subscription data in the HLR/HSS. This subscription data may be stored in a 
Multiple Subscriber Profile (MSP), with the HLR/HSS able to hold a number of MSPs per IMSI. 

LCS UE subscription data includes a privacy exception list containing the privacy classes for which location of the 
target UE is permitted. Each privacy class is treated as a distinct supplementary service with its own supplementary 
service code. The following logical states are applicable to each privacy class (refer to TS 23.011 [22] for an 
explanation of the notation). 
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Table 10.1 : Logical States for each LCS Privacy Class 



Provisioning State 


Registration State 


Activation State 


HLR Induction State 


(Not Provisioned, 


Not Applicable, 


Not Active, 


Not Induced) 


(Provisioned, 


Not Applicable, 


Active and Operative, 


Not Induced) 



For each LCS privacy class, the HLR/HSS shall store the logical state of the class on a per-subscriber (or per subscriber 
MSP) basis. In addition, the permanent data indicated below shall be stored on a per subscriber (or per subscriber MSP) 
basis when the logical provisioning state of the associated LCS privacy class is "provisioned". For the meaning of each 
LCS privacy class, refer to clause 9 and to TS 22.071 [4]. 
Moreover a list of allowed service types may be stored. The meaning of service types is defined in TS 22.071 [4]. 
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Table 10.2: LCS data stored in the HLR privacy exception list for an UE Subscriber 

(or UE Subscriber IVISP) 



LCS Privacy Class 


Status 


Additional HLR Data when Class is provisioned 


Universal Class 


- 


No additional data 


Call/session Related Class 


M 


C 



c 


Indication of one of the following mutually exclusive options for any LCS 
client not in the external LCS client list: 

• Location not allowed 

• Location allowed without notification (default case) 

• Location allowed with notification 

• Location with notification and privacy verification; location 
allowed if no response 

• Location with notification and privacy verification; location 
restricted if no response 

External LCS client list: a list of zero or more LCS clients, with the 
following data stored for each LCS client in the list: 

• International E.1 64 address identifying a single LCS client or a 
single group of LCS clients that are permitted to locate this 
target UE 

• Restriction on the GIVILC. Possible values are: 

Identified GIVILCs only 

Any GMLC in the home country 

• Indication of one of the following mutually exclusive options: 

Location allowed without notification (default case) 

Location allowed with notification 

Location with notification and privacy verification; location 

allowed if no response 

Location with notification and privacy verification; location 

restricted if no response 


Call/session Unrelated Class 


M 


c 



c 


Indication of one of the following mutually exclusive options for any LCS 
client not in the external LCS client list: 

• Location not allowed (default case) 

• Location allowed with notification 

• Location with notification and privacy verification; location 
allowed if no response 

• Location with notification and privacy verification; location 
restricted if no response 

External LCS client list: a list of zero or more LCS clients, with the 
following data stored for each LCS client in the list: 

• International E.1 64 address identifying a single LCS client or a 
single group of LCS clients that are permitted to locate this 
target UE 

• Restriction on the GMLC. Possible values are: 

Identified GMLCs only 

Any GMLC in the home country 

• Indication of one of the following mutually exclusive options: 

Location allowed without notification (default case) 

Location allowed with notification 

Location with notification and privacy verification; location 

allowed if no response 

Location with notification and privacy verification; location 

restricted if no response 


PLMN Operator Class 





LCS client list: a list of one or more generic classes of LCS client that 
are allowed to locate the particular UE. The following classes are 
distinguished: 

• LCS client broadcasting location related Information 

• O&M LCS client in the HPLMN 

• O&M LCS client in the VPLMN 

• LCS client recording anonymous location information 

• LCS Client supporting a bearer service, teleservice or 
supplementary service to the target UE 
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Table 10.3: LCS Service types stored in the HLR/HSS per UE subscriber 



Service type indication 


Status 


Additional HLR data when the indication is stored 


Service Types 





c 


Service types list: a list of one or more service types for which the LCS 
client is allowed to locate the particular UE. The possible service types 
are defined in 22.071 . The following data may be present for each 
service type in the list: 

• Restriction on the GIVILC. Possible values are: 
Identified GIVILCs only 
Any GMLC in the home country 

• Indication of one of the following mutually exclusive 
options: 

Location allowed without notification (default case) 
Location allowed with notification 
Location with notification and privacy verification; 
location allowed if no response 
Location with notification and privacy verification; 
location restricted if no response 



LCS UE subscription data may include a mobile originating list containing the LCS mobile originating classes that an 
UE is permitted to request. Each LCS mobile originating class is treated as a distinct supplementary service with its 
own supplementary service code. The following logical states are applicable to each mobile originating class (refer to 
TS 23.011 [22] for an explanation of the notation). 

Table 10.4: Logical States for each Mobile Originating LCS Class 



Provisioning State 


Registration State 


Activation State 


HLR Induction State 


(Not Provisioned, 


Not Applicable, 


Not Active, 


Not Induced) 


(Provisioned, 


Not Applicable, 


Active and Operative, 


Not Induced) 



For each LCS Mobile Originating class, the HLR/HSS shall store the logical state of the class on a per-subscriber (or 
per subscriber MSP) basis. In this version of LCS, there is no additional permanent data in the HLR. The table below 
shows the defined mobile originating classes. For the meaning of each LCS mobile originating class, refer to clause 8 
and to TS 22.071 [4]. 

Table 10.5: Data stored in the HLR for the LCS Mobile Originating List for an UE 

(or UE Subscriber MSP) 



LCS Mobile Originating 
Class 


Status 


Additional HLR Data when Class is provisioned 


Basic Self Location 


- 


No additional data 


Autonomous Self Location 


- 


No additional data 


Transfer to Third Party 


- 


No additional data 



In addition to the privacy exception list, the following other data itemsmay be stored in the UE subscription profile in 
the HLR to support LCS. 

Table 10.6a: Temporary LCS data in the HLR 



Other Data in the HLR 


Status 


Description 


GMLC List 





List of one or more E.164 addresses of the GMLCs from which a 
location request for an MT-LR is allowed. The addresses are only 
relevant to an LCS client that is restricted (in the UE privacy exception 
list) to making call/session related or call/session unrelated location 
requests. 
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10.2 VLR/SGSN 

The VLR/SGSN contains the same LCS permanent data for each registered UE subscriber, as does the HLR/HSS. This 
data is downloaded to the VLR/SGSN as part of the location update procedure between the VLR/SGSN and HLR/HSS 
for an UE subscriber. 

10.3 GMLC 

1 0.3.1 LCS Data in the GMLC for a LCS Client 

The GMLC holds data for a set of external LCS clients that may make call related or non-call related 
CS-MT-LR/PS-MT-LR requests to this GMLC. The permanent data administered for each LCS client is as follows. 



£75/ 



3GPP TS 23.271 version 5.12.0 Release 5 



71 



ETSI TS 123 271 V5.12.0 (2004-09) 



TablelO.7: GMLC Permanent Data for a LCS Client 



LCS Client data in GMLC 


Status 


Description 


LCS Client Type 


M 


Identifies the type LCS client from among the following: 
Emergency Services 
Value Added Services 
PLMN Operator Services 
Lawful Intercept Services 


External identity 





A list of one or more identifiers used to identify an external LCS client. 
The identity may be used when making an IVIT-LR and/or MO-LR. The 
format of the identity is international E.164 addresses. Each external 
identity shall be associated with a logical client name. 


Authentication data 


M 


Data employed to authenticate the identity of an LCS client - details are 
outside the scope of the present document 


Call/session related identity 





A list of one or more international E.164 addresses, which are used to 
make calls by mobile subscribers, or APN-NIs (see NOTE) to identify the 
client for a call related MT-LR 

In case the LCS client was reached via IN or abbreviated number routing 
(e.g. toll free number or emergency call routing), the E.1 64 number(s) 
stored in the GMLC shall be the number(s) that the UE has to dial to 
reach the LCS Client. In these cases the E.1 64 number is not to be in 
international format. The country in which the national specific number(s) 
is (are) applicable is (are) also stored (or implied) in this case. 
Each call related identity may be associated with a specific external 
identity. Each call/session-related identity shall be associated with a 
logical client name. 


Internal identity 





Identifies the type PLIVIN operator services and the following classes are 
distinguished: 

LCS client broadcasting location related information 

O&M LCS client in the HPLMN 

O&M LCS client in the VPLMN 

LCS client recording anonymous location information 

LCS Client supporting a bearer service, teleservice or 

supplementary service to the target UE 
This identity is applicable only to PLIVIN Operator Services. 


Client name 





An address string which is associated with LCS client's external identity 
(i.e., E.164 address). See note 2. 


Override capability 





Indication of whether the LCS client possesses the override capability 
(not applicable to a value added and PLIVIN operator service) 


Authorized UE List 





A list of IVISISDNs or groups of MSISDN for which the LCS client may 
issue a non-call related MT-LR. Separate lists of MSISDNs and groups of 
MSISDN may be associated with each distinct external or non-call related 
client identity. 


Priority 


M 


The priority of the LCS client - to be treated as either the default priority 
when priority is not negotiated between the LCS server and client or the 
highest allowed priority when priority is negotiated 


QoS parameters 


M 


The default QoS requirements for the LCS client, comprising: 

Accuracy 

Response time 
Separate default QoS parameters may be maintained for each distinct 
LCS client identity (external, non-call related, call related) 


Allowed LCS Request Types 


M 


Indicates which of the following are allowed: 

Non-call related CS-MT-LR/PS-MT-LR 
Call/session related CS-MT-LR/PS-MT-LR 
Specification or negotiation of priority 
Specification or negotiation of QoS parameters 
Request of current location 
Request of current or last known location 


Local Co-ordinate System 





Definition of the co-ordinate system(s) in which a location estimate shall 
be provided - details are outside the scope of the present document 


Access Barring List(s) 





List(s) of MSISDNs or groups of MSISDN for which a location request is 
barred 


Service Identities 





List of service identities allowed for the LCS client. 



NOTE 1: The LCS Client is identified with E.164 number or APN-NI. APN-NI is specified in TS 23.003. 

NOTE 2. The LCS Client name should not contain two equal signs, because those characters are used to separate LCS 
client name from Requestor ID when GLMC includes them into the same field. 
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1 0.3.2 LCS Data in the GMLC for a UE Subscriber 

GMLC may store a codeword handling information and a list of Codewords given by the UE subscriber in order not to 
get the location request rejected. 

Table 10.8a: Codeword handling information stored in the GIVILC 



Other Data in the GMLC 


Status 


Description 


Codeword handling 
information 





Indication of one of the following mutually exclusive options for 
codeword: 

• codeword shall be checked in network. 

• codeword shall be sent to UE 



Table 10.8b: Codeword list stored in the GIVILC for a UE Subscriber 



LCS Privacy profile 


Status 


Additional GMLC data when profile is provisioned 


Codeword 





A list of codeword. 



If the GMLC stores the codeword handling information and/or the codeword list for the target UE, the restriction on the 
GMLC in SLPP shall be set as Identified GMLCs only', and only the GMLC that stores the codeword related 
information shall be included in the GMLC list stored in HLR/HSS. 

10.4 Recovery and Restoration Procedures 

The LCS recovery and restoration procedures allow temporary data to be recovered or reinitialized following loss or 
corruption of data, such that normal LCS service is rapidly restored and inconsistency between the data held by 
different LCS network elements is removed. For a full description, refer to TS 23.007 [23]. 

10.5 Interworking between network nodes in different releases 

This clause describes possible scenarios for interworking between network nodes in different releases. 

10.5.1 LCS capability set 

The following LCS capabilities are identified in the current version of this specification. The HLR/HSS is notified the 
LCS capability of the serving node by an indication, which indicates all the LCS capabilities the serving node supports, 
from the serving node during location update procedure. 

- LCS capability set 1 : R98 and R99 LCS (pre-Rel"4 LCS) 

- LCS capability set 2: Rel"4 LCS 

- LCS capability set 3: Rel"5 or later LCS 

The serving node, which notified the HLR/HSS that it supports LCS capability set 2, shall be able to handle the 
extended LCS Client list and LCS Client List for call-related class from the HLR/HSS. 

The serving node, which notified the HLR/HSS that it supports LCS capability set 3, shall support the following 
capabilities: 

capability to perform the service type privacy check. 

capability to send the codeword to target UE for notification/verification. 

capability to send the requestor ID to target UE for notification/verification. 
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1 0.5.2 Interworking between pre Rel-4 serving node and Rel-4 or later 
HLR/HSS 

The serving node that supports only pre-Rer4 LCS cannot handle the extended privacy control for call-related/call- 
unrelated class of the Rer4 and later LCS. That is, the serving node cannot provide the extended call-related/call- 
unrelated class service to the user who subscribes to the Rer4 LCS. Therefore HLR/HSS does not send the LCS 
subscriber data on call-related/call-unrelated class for users who subscribe to the call-related class of Rer4 LCS to the 
serving node that supports only pre-Rer4 LCS. 

1 0.5.3 Interworking between pre Rel-5 serving node and Rel-5 or later 
HLR/HSS 

If the HLR/HSS is notified that the LCS capability set 3 is not supported by the serving node, it may decide not to send 
the LCS subscriber data to the serving node, in order to protect user privacy. 

In addition, if the HLR/HSS is notified that the serving node does not support the LCS capability set 2, the procedures 
described in 10.5.2 also shall be applied. 

Note: this interworking scenario can be also applied for PS domain. Generalization of the description in this sub 
clause to cover both CS and PS domain should be done.][Note2: the concept of LCS capability set is 
introduced in Re 14 so that it doesn"t appear in the specifications for R98 and R99 LCS. 



1 1 Operational Aspects 



11.1 Charging 

Charging Information collected by the PLMN serving the LCS Client. 

The following charging information shall be collected by the PLMN serving the LCS Client: 

type and identity of the LCS Client; 

identity of the target UE; 

results (e.g. success/failure, method used if known, response time, accuracy) - to be repeated for each instance of 
positioning for a deferred location request; 

- identity of the visited PLMN; 

- LCS request type (i.e. LDR or LIR); 
state; 

event (applicable to LDR requests only); 

time stamp; 

type of co-ordinate system used. 



£75/ 



3GPP TS 23.271 version 5.1 2.0 Release 5 74 ETSI TS 1 23 271 V5.1 2.0 (2004-09) 

1 1 .2 Charging Information Collected by the Visited PLMN 

The following charging information shall be collected by the visited PLMN: 

tate and time; 

type and identity of the LCS Client (if known); 

identity of the target UE; 

location of the target UE (e.g., MSC, MSC Server, SGSN, location area ID, cell ID, location co-ordinates); 

which location services were requested; 

results (e.g. success/failure, positioning method used, response time, accuracy) - to be repeated for each instance 
of positioning for a batch location request; 

- identity of the GMLC or PLMN serving the LCS Client; 

state; 

event (applicable to LDR requests only). 
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Annex A (normative): 
Privacy Class selection rule 



If more than one privacy class are subscribed or in case Service Types and at least one privacy class are subscribed, 
privacy class for an MT-LR is selected according to the following flow diagram. 



An MT-LR may be applied to more than one privacy class or to Service Types and one or more privacy classes. In this 
case, looser privacy setting shall be selected. All possible privacy setting values are listed in the table below. The 
privacy settings to be compared are the results of the privacy checks for each applicable class and Service Type. The 
interrelation among each privacy setting in terms of privacy strictness is shown as follows: 



loose 

t 



i 
strict 



Positioning allowed without notifying the UE user 

Positioning allowed with notification to the UE user 

Positioning requires notification and verification by the UE user; positioning is allowed only if 

granted by the UE user or if there is no response to the notification 

Positioning requires notification and verification by the UE user; positioning is allowed only if 

granted by the UE user 

Positioning not allowed 



Call Related/Call 
Unrelated class 

[Note4] 




PLMN Operator 
class 



The location request is not 
aiiowed unconditionally 



Tine location request is not 
aiiowed unconditionally 



Call Related 
class 



Call Unrelated 
class 



Tine location request is not 
allowed unconditionally 



Figure A.I : Privacy Class selection flow diagram 
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Note 1 : The client type indicates PLMN Operator service, and tlie client is witliin or associated witli the VPLMN. 
Note 2: The client type indicates value added service; the UE originated call/session to the requesting LCS client is 

established and the address associated to the LCS client used by the UE in call/session set up matches 

with that contained in the location request. 
Note 3: The client type indicates value added service. 
Note 4: The looser privacy setting shall be selected. 

If the user subscribes Service Types, once that the privacy class has been selected according to figure A. 1, the resulting 
privacy setting shall be compared with the result of Service Type privacy checking, and the looser condition shall be 
applied to the MT-LR, provided that the LCS client was authorized by the UE user to get location information. 
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Annex B (normative): 

Presence of LCS client ID Components in IVIT-LR 

The LCS client identity is composed of one or more than one of the following components: LCS client type, external 
identity, internal identity, call/session related identity, APN-NI, client name and Requestor Identity. The LCS client 
type shall always be present and for each LCS client type the presence of the other components are defined as follows: 



Component 
LCS Client type 


External 
identity 


Internal 
identity 


Call/session 
related identity 


Client name 


Requestor 
Identity 


Emergency 


O 


N.A. 


N.A. 


N.A. 


N.A. 


Value added 


M 


N.A. 


O [Note] 


M 





PLMN operator 


N.A. 


M 


N.A. 


N.A. 


N.A. 


Lawful Intercept 


N.A. 


N.A. 


N.A. 


N.A. 


N.A. 



Note: This component shall be present if the MT-LR is associated to either CS call or PS session. If the MT-LR 
is associated with the CS call, the number dialled by UE is used. Otherwise if the MT-LR is associated 
with the PS session, the APN-NI is used. 
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Annex C (normative): 

including Requestor identity to LCS client name 

In case the MSC/SGSN or the UE is pre Rel-5 then there is no possibiHty to send the Requestor identity to the UE in a 
new separate parameter. To obtain this backward compatibility the GMLC can add the Requestor identity to LCS cUent 
name. 

In order to offer best possible service for the end user the UE should be able to differentiate LCS client name and 
Requestor ID when they are included in to a same parameter. Also it is important that the LCS client name and the 
Requestor ID are separated with a consistent manner. Therefore there is a need to define a rule how the GMLC should 
separate LCS client name and Requestor identity. In the box below is described the practice how the LCS cUent name 
and Requestor identity should be separated. 



LCS clientName==RequestorIdentity 



LCS client name and Requestor identity are separated with two equal signs. 

Note: It is possible that the Requestor identity does not fit into the LCS client name field. In that case as many 
characters as possible from the beginning is added to the LCS client name field. 
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Annex D (informative): 
Change history 



Date 


Version 


Comment 


September 2000 


1.0.0 


Presented for information to SA#9. 


21.11.00 


1.1.0 


Changes and additions from LCS drafting group 16.11.00, 
sent out for S2 e-mail approval 


4.12.00 


1.2.0 


S2 e-mail comments received before 4.12.00 included 


10.12.00 


2.0.0 


For approval at SA#10. Same content as v.1 .2.0 


31.01.01 


4.0.0 


Cleaning up of v.2.0.0. Same technical content as in 2.0.0. 


05.04.01 


4.1.0 


CRs approved at TSG SA Plenary #1 1 in IVIarch 2001 included 


30.06.01 


4.2.0 


CRs approved at TSG SA Plenary #1 2 in June 2001 included (SP-01 0371 ) 



Document history 


5.0.0 


October 2001 


Created from v.4.3.0 -i- CR approved at TSG SA#1 3: 

035rev1 Release 5 alignment of 23.271 with GERAN LCS stage 2, TS 43.059 


5.1.0 


December 2001 


CRs approved at TSG SA Plenary #14 in December 2001 included: 

038r1 LCS Capability Handling for GPRS IVIS"s 

042r1 Removal of PDP address from HLR/HSS in the IVIT-LR procedure 

044 Response to LCS client in case of deferred IVIT-LR 

049r1 SGSN Exception procedures 

051 r1 Correction of referred signaling step in MO-Location Request 

055 Editorial correction to front page 


5.2.0 


IVIarch 2002 


CRs approved at TSG SA Plenary #15 in IVIarch 2002: 

057 Supported LCS capabilities sets 

059r3 Clarification of OSA support for LCS in TS23.271 

061 r1 Requestor and Requestor Identity 

062r1 Combined Periodical/Deferred Mobile Terminating Location Request 

064 Essential correction for session related class 

065r2 Adding references to the LIF MLP specification for the Le interface 

069r1 Handling of service type and codeword 

071 r1 Handling of privacy override indicator 

072r2 Correction of information flows LCS client - GMLC 

077r1 Removal of NA-ESRK from MT-LR request for North American Emergency call 


5.3.0 


June 2002 


Incorporation of CRs approved at TSG SA Plenary #16 in June 2002: 

83 Handling of Location request without Codeword in GMLC 

87rev1 Clarification of CS-MO-LR/PS-MO-LR procedures 

88 Deleting version number of Mobile Location Protocol Specification from reference 

89rev1 Service type and codeword clarifications 

90 Requestor identity in LCS client name 

91 revi Privacy Class selection rule 

82rev3 Modification to LCS to support North American E91 1 
85rev3 Definition of 'Enhanced User Privacy' 
84rev5 Codeword check mechanism. 


5.4.0 


September 2002 


Incorporation of CRs approved at TSG SA Plenary #17 in September 2002: 

96 Handling of codeword in case of combined periodical/deferred MT-LR 

1 0Orl Privacy procedure correction 

1 02r1 Removal of IMS in LCS for call/session related class 

1 lOrl Clarification of Interworking mechanism between network nodes in different 

releases (incorporated in v.5.5.0) 

1 1 5r1 Receiving the deferred MT-LR for the UE during waiting for the event of the 

same UE 


5.5.0 


December 2002 


Incorporation of CRs approved at TSG SA Plenary #18 in December 2002: 
1 33 Addition of reference number to deferred MT-LR procedure 
1 21 r1 Clarification of codeword handling mechanism 
1 09r1 Privacy class selection rule 


5.6.0 


March 2003 


Incorporation of CRs approved at TSG SA Plenary #19 in March 2003: 
147rev2 Clarification to Requestor ID in LCS client name 


5.7.0 


June 2003 


Incorporation of CRs approved at TSG SA Plenary #20 in June 2003: 

168r2 Exception procedures in 23.271 

1 75 CR on 23.271 : Correction to NI-LR for Emergency Services 

1 81 r3 Addition of Position Method Used, to attributes returned with location estimate 
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5.8.0 


September 2003 


Incorporation of CRs approved at TSG SA Plenary #21 in September 2003: 
207 Removing PDP addressing of the target UE 
21 1 Correcting reference to LIF-MLP specification 


5.9.0 


December 2003 


Incorporation of CRs approved at TSG SA Plenary #22 in December 2003: 

225 Addition of Position Method Used, to attributes returned with location estimate 

228r2 Enhanced LDR reference number in R5 


5.10.0 


March 2004 


Incorporation of CR approved at TSG SA plenary #23 : 

246 Routing of Emergency Calls based on Geographical Coordinates 
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